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

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

S>>Прости, но твое итоговое мнение основано на какой именно классификации?

_>Моё мнение основано на:
_>- знание определения понятия "параметрический полиморфизм" и целей его возникновения
Знаю, но никому не скажу, особенно про источник.

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

_>Этого более чем достаточно для подобных выводов.
Кому — как. Мне этого не достаточно что бы принять твои выводы.

S>>Ну причем тут производительность? Каким образом производительность C++ влияет на классификацию?

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

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

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

_>Из определения понятия "полиморфизм". )))
Ты боишься что ли привести определение, которое знаешь и которым пользуешься?

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

_>Совершенно верно. И какую ты тут видишь разницу со случаем equal_to (заменяем его на f, а оператор равенства на xrmbrm)?
никакой. Потому и заявляю, что equals_to — ad hoc, т.к. требует специализации чуть ли не для всех типов.

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

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