Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.129.63.114] |
|
Страницы: (33) « Первая ... 11 12 [13] 14 15 ... 32 33 ( Перейти к последнему сообщению ) |
Сообщ.
#181
,
|
|
|
В Сишных макросах тоже не любой произвольный текст можно использовать. Есть ограничения.
|
Сообщ.
#182
,
|
|
|
Цитата amk @ В Сишных макросах тоже не любой произвольный текст можно использовать. Есть ограничения. Оу, не знал. Но там всё же "посвободней", чем в шаблонах? |
Сообщ.
#183
,
|
|
|
Достаточно, чтобы строка через лексический анализатор проходила без ошибок.
|
Сообщ.
#184
,
|
|
|
Это ты сам придумал такое определение? Я вот в педивикии не вижу такого обязательного требования:
Цитата Я не вижу причин несоответсвия плюсовых шаблонов этому определению. Может есть какое-то иное определение? Дай ссылку.Параметрический полиморфизм позволяет определять функцию или тип данных обобщённо, так что значения обрабатываются идентично вне зависимости от их типа. Параметрически полиморфная функция использует аргументы на основе поведения, а не значения, апеллируя лишь к необходимым ей свойствам аргументов, что делает её применимой в любом контексте, где тип объекта удовлетворяет заданным требованиям поведения. Таким образом, реализуется концепция параметричности Цитата D_KEY @ Зачем объяснять? Я в целом понимаю, чем отличается система типов Хаскеля и плюсов. Я не понимаю, почему ты считаещь это различие достаточным для того чтобы утверждать, что шаблонные функции C++ не полиморфны параметрически.Не будет. Их будет много(возможно) в сгенеренном коде. Но в системе типов будет ровно один тип. И ровно одна функция. Тайпчекер работает с парметрами полиморфного типа практически как с типовыми переменными. В общем, объяснять долго, а толку будет мало У нас разногласия фактически на уровне терминологии. Я считаю, что такую вот "имитацию" можно считать параметрическим полиморфизмом. Цитата korvin @ Нэть, шаблоны обрабатываются компилятором, а не препроцессором, со всеми вытекающими. Разница огромна.Тем, что это почти просто текстовая подстановка, почти как макросы (что Сишные, что Лисповые) или HTML-шаблоны, не более того. Ну вообще-то, в похапе любая функция полиморфна по всем параметрам. Добавлено Цитата korvin @ Я упоминал в соответствующем холиворе. Но народ не оценил. Дескать в Nemerle макросы круче. Не спорю, там (в Nemerle) красота, но в целом возможность любую текстовую строку компильнуть как D-шный код, в купе с произвольным CTFE - весьма приятная штука. Кстати, не знаю, упоминалось ли тут (в разделе вообще), но в D термин mixin имеет два значения: один обще принятый, а второй --- как раз что-то вроде текстовых подстановок (чуть более продвинутых, чем Сишный препроцессор, но менее продвинутых, чем лисповые макросы). |
Сообщ.
#185
,
|
|
|
Цитата applegame @ Нэть, шаблоны обрабатываются компилятором, а не препроцессором, со всеми вытекающими. Разница огромна. Ну вообще-то, в похапе любая функция полиморфна по всем параметрам. Лисповые макросы тоже обрабатываются компилятором. Так в чём огромность разницы? Да не совсем, для динамической типизации все эти рассуждения довольно эфемерны. Более того, там всё универсально-полиморфно, а не параметрически, т.к. последний имеет смысл только при статической типизации. |
Сообщ.
#186
,
|
|
|
Цитата D_KEY @ Я не против сравнения дженериков и шаблонов, D_KEY, я против того, что те и другие были поставлены в равные условия, коли речь в постановке задачи касается терминов "compile-time" и "run-time". Из-за неопытности (?) автора получилось нечто подобное сравнению полнофункционального std::vector<> и динамического C-массива с нереализованным контролем стораджа. Естественно std::vector<> проиграет, и либо вместо него взять следовало std::array<>, либо дореализовать фичу перераспределения стораджа для C-массива.Смысл в том, что система типов поможет нам гарантировать, что длина будет одной и той же. Называй как хочешь. Объясняю на пальцах. Дженерики инстанцируются в run-time, при этом получается новый байт-код. Если есть jit-компиляция, то она будет произведена, а значит термин "run-time" уже неполно характеризует происходящие в нём процессы, т.к. подразумевает "compile-time" уже во время "run-time"; если же jit-а нет, то термин "compile-time" вообще неприменим в данном случае, ибо новый байт-код будет интерпретироваться. С тем же успехом можно на Плюсах реализовать – правда, придётся это делать руками, но никто не мешает на будущее запилить сие себе в библиотеку – досоздание исполняемого объектного кода, и C# тут отнюдь не окажется в выигрыше. Или попробовать сравнить C# и банальным GW-Basic, где последний заткнёт его за пояс однозначно. Цитата D_KEY @ D_KEY, ты меня удивляешь. Полиморфизм не имеет никакого отношения к типам. Он имеет отношение к поведению. Впрочем, я догадываюсь, каким будет следующее возражение. Шаблонный код не полиморфен уже на уровне системы типов. Вот в чем проблема(для данного примера). |
Сообщ.
#187
,
|
|
|
Цитата korvin @ С Лиспом не знаю. Я про сишные макросы.Лисповые макросы тоже обрабатываются компилятором. Так в чём огромность разницы? Цитата korvin @ Ты уверен? Пруф можно? Что-то я не встречал такого странного условия для параметрического полиморфизма - статическая типизация.а не параметрически, т.к. последний имеет смысл только при статической типизации. Добавлено Предлягаю вынести спор о плюсовом полиморфизме в отдельный холивор |
Сообщ.
#188
,
|
|
|
Цитата applegame @ Ты уверен? Пруф можно? Что-то я не встречал такого странного условия для параметрического полиморфизма - статическая типизация. Я уверен на 100%. Параметрический полиморфизм(ПП) параметризуется типами, что совершенно бессмысленно при динамической типизации, т.к. там в любом случае типы приходится выяснять в рантайме и то только если нужно. Фактически ПП нужен для "обхода" ограничений примитивной статической типизации и написания обощённого кода. Попробуй написать функцию len, вычисляющую длину списка в Лиспе(да вообще в любом ЯП с дин. типизацией) и в D (вообще в любом ЯП со статической типизацией) и в (оригинальном)Паскале, например. |
Сообщ.
#189
,
|
|
|
Цитата korvin @ Попробуй написать функцию len, вычисляющую длину списка в Лиспе(да вообще в любом ЯП с дин. типизацией) и в D (вообще в любом ЯП со статической типизацией) и в (оригинальном)Паскале, например. Да чего уж так сложно то? Банальный жабоскрипт function f(a, b) { return a+b; } будет работать для кучи типов. В языках со статической типизацией возникнут проблемы. |
Сообщ.
#190
,
|
|
|
Цитата korvin @ Можно. Это называется экспортом шаблона. Существует с C++98. Тот факт, что реализован он только в одном-единственном компиляторе, лично я считаю сознательным саботажем со стороны поставщиков реализации. С C++11 по этой причине экспорт шаблонов не является обязательным.В C++ же нельзя запихнуть шаблонную функцию в файл реализации, выставив в хэдер только сигнатуру? Однако положа руку на сердце, я признаю, что работать с шаблоном, не имея его сырцов, в условиях отсутствия концептов при отладке своего можно получить геморр ещё тот. |
Сообщ.
#191
,
|
|
|
Цитата applegame @ Это ты сам придумал такое определение? Это не определение. Я пытался объяснить разницу между параметрическим полиморфизмом уровня системы типов и параметрическим полиморфизмом на уровне кода(что мы наблюдаем в C++ и D). Параметрический полиморфизм есть в C++(признаю таки), но там нет полиморфных типов. Уже не знаю, как еще сказать. И не думаю, что мы способны извлечь что-либо болезное из продолжения данного спора |
Сообщ.
#192
,
|
|
|
Цитата korvin @ Давай не будем сызнова реинкарнировать ещё одну давным-давно избитую до смерти тему. У макросов с шаблонами примерно столько же общего, как у телефонистки и сотового: результат похож, но это и всё. Тем, что это почти просто текстовая подстановка, почти как макросы (что Сишные, что Лисповые) или HTML-шаблоны, не более того. |
Сообщ.
#193
,
|
|
|
Цитата Qraizer @ я против того, что те и другие были поставлены в равные условия, коли речь в постановке задачи касается терминов "compile-time" и "run-time". Хм. Обсуждается-то скорее система типов. Система типов с дженериками или полиморфными типами позволяет разбирать случаи из примера поскольку тайпчекер знает, что работает с полиморфными типами, ему не надо полностью что-либо инстанцировать, он итак может осуществить необходимые проверки. Ты же больше об имплементации говоришь. Цитата Дженерики инстанцируются в run-time, при этом получается новый байт-код. Не обязательно. Они вообще могут не инстанцироваться и не генерировать байт-код во время исполнения. Если мы о дженериках. Не знаю, как там в последних версиях, но JVM очень долго(а может и сейчас) ничего о дженериках не знала и компилятор там генерировал код для Object и обеспечивал boxing/unboxing для встроенных типов. Цитата С тем же успехом можно на Плюсах реализовать – правда, придётся это делать руками, но никто не мешает на будущее запилить сие себе в библиотеку – досоздание исполняемого объектного кода Есть libjit, например. Если я правильно тебя понял. Но суть-то не в том, что там и когда мы генерируем. Вопрос в том, кто и как проверяет. Система типов C++ не знает про шаблоны, шаблоны сначала инстанцируются и сначала мы получаем тип, а потом уже осуществляется с ним работа. Потому тайпчекер не приступит к работе, пока мы не инстанцируем тип. В случае же полиморных типов инстанцировать тип нет необходимости(кроме случаев оптимизации). Добавлено Цитата MyNameIsIgor @ Цитата korvin @ Попробуй написать функцию len, вычисляющую длину списка в Лиспе(да вообще в любом ЯП с дин. типизацией) и в D (вообще в любом ЯП со статической типизацией) и в (оригинальном)Паскале, например. Да чего уж так сложно то? Банальный жабоскрипт function f(a, b) { return a+b; } будет работать для кучи типов. В языках со статической типизацией возникнут проблемы. Пример со списком более "чист" из-за отсутствия требований к типам. Списку все равно, что хранить. |
Сообщ.
#194
,
|
|
|
Не буду цитировать, мне сейчас крайне неудобно красиво оформлять посты, я в Крыму с ноутом жены. Просто пронумерую по порядку.
|
Сообщ.
#195
,
|
|
|
Цитата Qraizer @ Я вошёл в спор с целью показать неверность вывода того хаскелиста (что кем он там являлся-то). Он взял некую сущность из одного языка и сравнил с похожей сущностью другого языка, проигнорировав тот факт, что эти сущности не просто разные, но и сферы их применения разные, и назначения тоже разные. Немудрено, что пришёл к неверному выводу. Но вывод там в том, что на C++ такую проверку сделать нельзя. И ведь действительно нельзя. |