Здравствуйте, samius, Вы писали:

_>>Ууу) Ты всё же решился свернуть на эту холиварную тему. Вопрос о сути шаблонов C++ уже давно является известной темой для споров. И на этом форуме и на других известных. Повторять все эти потоки флейма нет никакого желания — это всё можно найти на форуме самостоятельно. Так что просто выскажу своё итоговое мнение по данному вопросу, в сравнение с тем же Хаскелем:
S>Прости, но твое итоговое мнение основано на какой именно классификации?

Моё мнение основано на:
— знание определения понятия "параметрический полиморфизм" и целей его возникновения
— знание всех деталей работы шаблонов C++
— знание устройства полиморфизма в Хаскеле (для сравнения), ну и кстати дженериков в Java/C# (это разве для того чтобы посмеяться, т.к. самая убогая реализация из всех упомянутых) тоже.

Этого более чем достаточно для подобных выводов.

_>>Основная цель всего этого механизма в том, чтобы облегчить работу программиста, позволив ему писать один код для всех случаев. Шаблоны из C++ это полностью реализуют. А с учётом ещё и вопроса производительности данное решение выглядит на голову лучше всех остальных реализаций. Ценой же этого (ну никогда не бывает идеала и у всех мощных технологий есть обратная сторона) являются большие сложности с введением в язык модулей.
S>Ну причем тут производительность? Каким образом производительность C++ влияет на классификацию?

А я ни про какие классификации здесь ничего и не говорил. Здесь я высказал своё оценочное суждение, о том что подход C++ (удобство и быстродействие в обмен на модульность) к решению данной проблемы является самым эффективным. Полезнее на практике подхода Хаскеля (удобство и модульность в обмен на быстродействие) и на голову лучше всяких убогих дженериков (где нет ни удобства, ни быстродействия).

S>>>Что значит "для многих типов"? Формально нужна работа для всех типов.
_>>С чего бы это? Откуда такое бредовое требование? Да ещё и формальное... )))
S>Я думаю что к нему можно прийти отсюда:
S>

S>Parametric polymorphism, the topic of this chapter, allows a single piece of code to be typed “generically,” using variables in place of actual types, and then instantiated with particular types as needed. Parametric definitions are uniform: all of their instances behave the same.

S>TAPL

Не вижу в этой цитате ничего даже близкого к требованию обеспечения работы для всех типов. Да его и не могло бы быть (иначе все остальные языки с поддержкой параметрического полиморфизма резко перестали бы ими быть)...

S>А откуда требование "для многих"?

Из определения понятия "полиморфизм". )))

_>>Т.е. если я напишу на Хаскеле функцию f вида "f a = xrmbrm a", то она по твоему обязательно будет работать для всех типов? )))
S>может быть и для всех, если у нас "xrmbrm = id"
S>а может и не для всех. Она возьмет ограничения из определения xrmbrm

Совершенно верно. И какую ты тут видишь разницу со случаем equal_to (заменяем его на f, а оператор равенства на xrmbrm)?

_>>>>И так, подводя итоги:
_>>>>1. equal_to — компаратор.
_>>>>2. работает с разными типами — полиморфный.
_>>>>3. имеет одну реализацию для всех типов — параметрический.
S>>>пожалуй, я найду тип, для которого стандартная реализация не работает. Точнее, мешает скомпилироваать проект.
_>>И? ) Это как-то влияет на аргументацию? )
S>что именно здесь не очевидно? если найдется тип, для которого equal_to требует специального уточнения (в исходниках), то это ad hoc (как минимум на уровне исходников), если ты предлагаешь подразделять полиморфизм исходников от полиморфизма исполняемого кода.

Ты похоже чего-то не понял. Ещё раз повторяю, стандартный equal_to (без всяких дополнительных специализаций) работает с любым типом, для которого определён оператор равенства. Из этого следует:

1. Что это параметрический полиморфизм (требования на работу со всеми возможными типами (включая не имеющие оператора равенства) — это лично твоё изобретение и не имеет ничего общего к действительности).
2. Если мы захотим, чтобы equal_to заработал с каким-то нашим новым типом, то мы просто добавим ему этот самый оператор равенства (а не пойдём добавлять специализации для equal_to) и стандартный equal_to мгновенно это подхватит и заработает и с этим типом. Так что при желание без проблем делается так, что equal_to будет работать со всеми типами в проекте, только на практике это обычно просто не нужно (глупо говорить например об операторе равенства для "класса приложения", так же как и глупо думать о манипуляциях с ним в контейнерах).