Я имею в виду, кроме его обязательного имени (Стандартная библиотека шаблонов) ...

Изначально C ++ предназначался для представления концепций ООП в C. То есть: вы могли бы сказать, что конкретная сущность могла и не могла делать (независимо от того, как она это делает), основываясь на своем классе и иерархии классов. Некоторые композиции способностей сложнее описать таким образом из-за проблематики множественного наследования и того факта, что C ++ поддерживает концепцию интерфейсов в некоторой степени неуклюже (по сравнению с Java и т. Д.), Но она есть (и может быть улучшено).

И тогда в игру вступили шаблоны вместе с STL. Похоже, что STL взял классические концепции ООП и уничтожил их, используя вместо этого шаблоны.

Должно быть различие между случаями, когда шаблоны используются для обобщения типов, когда сами типы типов не имеют отношения к работе шаблона (контейнеры, например). Иметьvector<int> имеет смысл.

Однако во многих других случаях (итераторы и алгоритмы) предполагается, что шаблонные типы должны следовать «концепции» (Input Iterator, Forward Iterator и т. Д.), Где фактические детали концепции полностью определяются реализацией функции / класса шаблона, а не классом типа, используемого с шаблоном, что несколько противоречит -использование ООП.

Например, вы можете сказать функцию:

<code>void MyFunc(ForwardIterator<...> *I);
</code>

Update: Как было неясно в исходном вопросе, ForwardIterator вполне может быть сам шаблонизированным, чтобы разрешить любой тип ForwardIterator. Напротив, в качестве концепции используется ForwardIterator.

ожидает прямого итератора, только взглянув на его определение, где вам нужно либо посмотреть на реализацию, либо на документацию для:

<code>template <typename Type> void MyFunc(Type *I);
</code>

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

Однако я ищу более глубокую причину, почему отказываться от классического ООП в пользу шаблонов для STL? (Предполагая, что вы читали это далеко: P)