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

R>Это относится и к явным интерфейсам. Они хорошо описывают лишь сигнатуры функций. Не больше и не меньше.
<...много пропущено...>
R>Потом "если ты не можешь создать экземпляр, ты должен возвращать -1, а не 0! ну ты блин даёшь!"

Ну идея возвращать -1 под видом указателя не может не радовать, а так в целом я с тобой согласен. Жизнь программистов и так трудна и Договориться между частями большого проекта и так непросто. Зачем это всё усугублять ещё и при помощи шаблонов?

R>Сигнатура функции — это лишь вершина айсберга. Это самая тривиальная часть.
R>Забывают комментировать и проверять (или скорее просто не думают об этом) как раз самые тонкие моменты
Проблема в том, что при программировании шаблонов тоже забывают, а момнетов намного больше. Поинт в том, что шаблоны обычно дают слишком много свободы. ЧТо и приводит к проблемам


E>>1в) Не понятно что делать, когда этот коментарий устаревает. Формальных проверок или нет или они чудовищны и ненадёжны. Вот понадобилось тебе, чтобы, скажем, сделать fff возвращал const MyInt&? Что вот делать? Вычитывать весь клиентский код во всех сделвнных на этом шаблоне проектах?

R>см. выше. Проблема неактуальности документации не имеет ничего общего к шаблонам.
Не совсем так. В C++ шаблонах очень прохо разделены интерфейс и реализация.
Вот правишь ты какой-то шаблонный класс. Переименовываешь приватные методы там, поля, ещё чего делаешь.
А у пользователя были частичные специализации каких-то методов твоей мульки. И что дальше делать?

R>А если например функция virtual SomeClass* fff() = 0; раньше была сама ответственна за удаление созданных экземпляров, а тебе понадобилось, что бы она пересала быть ответственна и не удаляла их. Что ты будешь делать? Вычитывать весь клиентский код во всех сделанный на этом интерфейсе проектах?

Лично я старую функцию оставлю для обратной совместимости, объявлю её obsolete, а для современного, правильного использования заведу функцию с другим названием.
А ты как поступаешь?


R>Решение: реализовать прототип класса, которым можно инстанциировать шаблон не в комментарии а в коде. И в каком-то месте инстанциировать им шаблон, что бы он компилировался, но не выполнялся. Проблема устаревания и полноты решена.
R>Я согласен, это сложнее, чем явный интерфейс, для этого надо обладать знаниями, что бы так сделать.

R>Далее — static_assert — с их помощью можно проверять уже классы, которыми пользователь специализирует твой шаблон. Проверить можно много. И даже больше, чем ты можешь проверить с помощью явного интерфейса!
R>Согласен, это опять же сложнее. Опять же надо обладать некими знаниями.

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

R>Далее — решение уже не только для шаблонов. Оно и явным интерфейсам костыли прикрутит. Модульные тесты. Проверяем горааааздо больше, чем явный интерфейс. Проверяем, кстати, и то, что virtual SomeClass* fff() = 0; сама удаляет память, и что она потокобезопасна, и что она не уидает исключения, и что в случае ошибки она возвращает именно -1.

Модульные тесты уведут нас очень далеко от темы обсуждения книжки Александреску.
Но в целом я согласен, что модульные тесты позволяют до какой-то степени улучшить качество кода, за счёт удорожания разработки. Если конечно вдруг их в каком-то проекте удаётся сделать и заставить нормально работать (не в смысле кодирования и отладки, а в смысле налаживания бизнес-процессов). Но я не понимаю почему плюсом является такое усложнение кода, при котором модульные тесты из полезных в некоторых критичных именно по качеству проектах становятся необходимыми повсеместно?
Может это говорит таки о том, что что-то мы таки переусложнили?

---

E>>Кроме того, есть у меня такое практическое наблюдение, что когда кто-то пишет шаблон и он при этом не супер спец этого дела, то получается изделие с неясной семантикой. Обычно я не придираясь, а просто стараясь понять что и как там втыкается, задаю вопросы, которые ставят авторов в тупик

R>При чём здесь шаблоны?
R>Я видел и обычные функции из 10 строк с неясной семантикой.

Шаблоны тут при том, что если средний программист пишет функцию, то она с ясной семантикой. А если шаблон -- то нет. Просто потому, что у функции намного лучше определён интерфейс, то есть есть хорошее место где подумать над семантикой

---

Но в целом я повторяю в чём именно я с тобой не согласен по существу.
Я всё-таки считаю, что чем проще и понятнее написана программа, тем лучше она написанна. Бывают действительно сложные задачи, где нужны сложные решения, тогда навороты реально упрощают программу. То есть вот вычислитель таблиц Брагиса, например, на С++ писать проще, чем на ассемблере, хоя ассемблер и проще. Но всё ещё его проще писать на С++, чем на С++, но с переносом всех вычислений в CT.

А ты считаешь, что если можно усложнить что-то, то надо. Ну и что, что для этого "Опять же надо обладать некими знаниями." и что это "Согласен, это опять же сложнее.". Но ведь если ещё и такой assert прикрутить и сякой и тесты модульные наладить, то типа бкдт нам счастье. А я не понмаю зачем. Единственный заметный мне эффект -- разработка требует больше времени, более продвинутых, то есть дорогих, программеров и становиться труднее в отладке и поддержке. А плюсы-то какие?