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

R>Ничто не мешает задать их так же явно. Например так:
R>

R>//Класс TLog должен быть copy-constructable и иметь следующий интерфейс:
R>struct TLog 
R>{
R>  void log(const std::string&);
R>  int fff();
R>};
R>

R>В следующей версии стандарта языка эту проблему возможно решат более элегантно.

Возможно решат, возможно не решат. Я так думаю, что решат, но не ту.
Но в текущем полложении дел есть несколько пробоем.
1а) Никто не гарантирует тебе, что этот твой комментарий соответсвует действительности. Вдруг *на самом деле* ты требуешь от TLog чего-то ещё. Или, наоборот, чего-то пока что не требуешь?
1б) НИкто не гарантирует, что твой комментарий будет правильно понят пользователем. Вдруг он напишет метод int& fff()? И в текущей версии шаблона всё будет хорошо, а потом ты что-то захочешь поправить? А формальной проверки не выполняется.
1в) Не понятно что делать, когда этот коментарий устаревает. Формальных проверок или нет или они чудовищны и ненадёжны. Вот понадобилось тебе, чтобы, скажем, сделать fff возвращал const MyInt&? Что вот делать? Вычитывать весь клиентский код во всех сделвнных на этом шаблоне проектах?

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

Общий смысл такой, что править шаблоны обычно дико дорого, поэтому их можно использовать либо в виде каких-то библиотечных очень хорошо отлаженных примитивов, скажем контейнеров. Либо в каких-то герметичных участках кода, где от чего-то надо несколько раз сдублировать код. Но только второе надо делать уже очень с опаской. Опять же про переиспользование таких шаблонов лучше всего забыть как правило сразу

R>Зато и возможностей больше. Гораздо больше. Причём принципиально новых. Вспомни хотя бы std::vector<>! Как ты его предлагаешь реализовывать без шаблонов? Или ты его не используешь?

Конечно я не возражаю, против шаблонного массива. Но std::vector те не менее не использую. У нас в конторе есть своя, более древняя библиотечка, которая конечно хуже STL, но предсказуемее. Например там более очевидны временные сложности операуий

Ну а если ты о тех новых возможностях, про которые пишет Александреску, то, ИМХО, они лишние

---

E>>2) Намного более сложный синтаксис и семантика. Вот, например, что тут написано:
E>>

E>>template<typename TLog>
E>>class Base {
E>>protected
E>>    void exit( int );
E>>};

E>>template<typename TLog>
E>>class MyExitProicessor : public Base<TLog> {
E>>public:
E>>    void OnExit( TLog& log, int code )
E>>    {
E>>        LogExit( log, code );  // это какой-то метод MyExitProicessor, описанный ниже
E>>        exit( code );
E>>    }
E>>};
E>>

R>Имхо. Всё понятно. Кстати, лучше писать "this->LogExit()" и "this->exit()", тогда и понятнее будет.

Может и лучше, но значит будет другое. Вообще-то в выделенной строке зовут функцию сишную exit .

---

E>>3) Очень неудобные сообщения об ошибках в пользовательском коде.

R>В большинстве случаев точно такие же как и без шаблонов. Надо просто их внимательно прочитать, а не говорить сразу "ух ты #$%, я это даже читать не буду". Вот ещё здесь.

К несчастью мне приходится это читать регулярно. Я так тебе скажу, что до изобретения STL я не встречал сообщений об ошибках, которые не помещаются в окно консоли

---

E>>А вот реальные преимущества всех этих трюков Александреску они в чём?
R>Меньше дублирования. Лучше понятны намерения программиста. Аспекты лучше выделены, а не замешаны в один клубок. Но это всё достигается за счёт наличия более сложного (интеллектуального) кода.
R>Я так считаю: можно иметь или много "тупого" кода (я его называю "raw"), это когда много накопипастеных функций, или меньше кода, но более "интеллектуального".

Прости, но мне кажется, что все преимущества, кроме "Лучше понятны намерения программиста" достигаются хорошим проектированием и реализацией кода задачи, а вовсе не применением головоломных конструкций из шаблонов
Что же касается намерений, то я согласен, что они понятны. Они обычно (явно или просто по факту) состоят в том, чтобы удорожить разарботку и сопровождение.