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

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

S>>Этот тезис уже не касается стандартной equal_to, т.к. одну версию для всех типов он не держит. Без специализации equal_to работает лишь для ограниченного количества типов и всегда найдется тип, для которого equal_to не работает "из коробки".

_>Стандартная equal_to работает для всех типов, для которых определён оператор равенства. Точно так же как и какой-нибудь vector<T> работает не для всех типов, а только для имеющих (как минимум) конструктор и оператор перемещения. Так что не пойму где ты тут увидел разницу с контейнерами STL.
Не знаю, откуда ты взял, что я увидел разницу с контейнерами STL. Я ведь не написал об этом? Согласно классификации, которую я привел (и которую ты проигнорировал), vector<T> — ad hoc.

S>>Я предлагаю обратиться к источнику классификации:

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

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

S>>И что, это работает для всех типов, или только для тех, у которых определен инстанс метод compare?

_>Для всех типов, у которых определена функция-член compare.
Вот видишь?

_>>>Но на самом деле все эти дополнительные доказательства уже не нужны, т.к. уже та самая простейшая обёртка является очевидным представителем параметрического полиморфизма — работает для многих типов и при этом в исходных кодах ровно одна реализация.
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.

TAPL

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

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

_>Или быть может в Хаскеле тоже нет параметрического полиморфизма? )))
Есть параметрический. Но есть и ad hoc. И я догадываюсь, как один отличить от другого.

S>>И одна реализация для всех, так, что бы даже компилятор и рантайм не нуждались в указании нужной реализции.

_>Ну это уже как раз тот самый спорный вопрос (см. выше).
Конечно тот же самый. Какую классификацию ты используешь?

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

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