Qt 4.4

>Однако мне не понятно почему Вам не нравятся шаблоны. По моему удобный инструмент...

А как они используются кроме для решения собственных проблем С++?
Если посмотреть на библиотеки идущие к коммерческим компиляторам типа
MSVC или BCB, то там иерархии классов строятся от базового объекта
типа CObject или TObject. Для борьбы с языком используется препроцессор,
грязные хаки c union{void (CObject::*ptr)(...), more_sane_types} (MFC)
и расширения наподобие __closure, __declspec(dynamic) (VCL).
В Qt тоже все наследуется от QObject и используется внешний
препроцессор moc. Несмотря на всю ту пургу что несет Строуструп
относительно того что иерархии в С++ должны быть
предметно-ориентированы и разрознены.

Особняком тут стоит WTL/ATL, где шаблоны применяются
для маршрутизации вызозов функций без применения C++ vTables.
Т.е примерно так:

template <class T> class B1 {
public:
void SayHi() {
T* pT = static_cast<T*>(this);
pT->PrintClassName();
}

void PrintClassName() { cout << "This is B1"; }
};

class D1 : public B1<D1> {
// No overridden functions at all
};

class D2 : public B1<D2> {
void PrintClassName() { cout << "This is D2"; }
};

int main() {
D1 d1;
D2 d2;
d1.SayHi(); // prints "This is B1"
d2.SayHi(); // prints "This is D2"
return 0;
}

В ObjectiveC связывание сообщения с обработчиком происходит
примерно как в WTL - статически вызывается селектор,
который ищет обработчик сообщения в самом нижнем классе и
при отсутствии оного делегирует сообщение вверх.
При достижении корня вызывается дефолтовый обработчик -
в win32 это DefWindowProc.
Т.е опять таки решаем собственные проблемы C++.

Ты можешь сказать что так круто сделать MyCoolLinkedList<T>.
Но это очень сомнительно, так как объекты удобнее складывать
в виде указателей, а не по значению т.к заколебешься для каждого
класса в большом проекте делать конструктор копирования,
функцию swap и operator=, упоминая каждое поле класса
три или четыре раза и при добавлении полей вносить минимум
три консистентных изменения. Проще поместить объект в кучу и
пользоваться указателем, который семантикой значений
обладает изначально.

Всякие вектора [x y z 1] и матрицы 4x4, которые вроде бы
напрашиваются на семантику значений, никто на C++ делать не будет.
Напишут на C + ASM в виде довольно крупных операций
покрывающих всю логику работы с ними.

Type Safety, который обеспечивает MyCoolLinkedList<T> по сравнению с
MyCoolObjectLinkedList содержащим указатели на базовый MyObject
и необходимость даункастинга (явного или неявного) при обращении
к элементам коллекции это FUD в основном. Теряем раздельную
компиляцию в обмен на чистоплюйство.

Звездишь, как дышишь :) В Qt не все наследуется от QObject moc - ни разу не препроцессор

> Ты можешь сказать что так круто сделать MyCoolLinkedList<T>.
Но это очень сомнительно, так как объекты удобнее складывать
в виде указателей, а не по значению т.к заколебешься для каждого
класса в большом проекте делать конструктор копирования,
функцию swap и operator=, упоминая каждое поле класса
три или четыре раза и при добавлении полей вносить минимум
три консистентных изменения. Проще поместить объект в кучу и
пользоваться указателем, который семантикой значений
обладает изначально.

MyCoolLinkedList<boost::shared_ptr<T> >

> Всякие вектора [x y z 1] и матрицы 4x4, которые вроде бы
напрашиваются на семантику значений, никто на C++ делать не будет.

возвр. значение: return T;
вызывающий код: const T& val=<возвр. значение>

>
Type Safety, который обеспечивает MyCoolLinkedList<T> по сравнению с
MyCoolObjectLinkedList содержащим указатели на базовый MyObject
и необходимость даункастинга (явного или неявного) при обращении
к элементам коллекции это FUD в основном. Теряем раздельную
компиляцию в обмен на чистоплюйство.

Разумное сочетание динамического и статического полиморфизма - ключевой момент в понимании и использовании С++. Если же Вам больше нравится LISP, Haskel или еще что - не вопрос вообще, у нас свободная страна.