我的意思是，除了它的名字标准模板库(后来演变成c++标准库)。
c++最初将面向对象的概念引入到C中，也就是说:您可以根据特定实体的类和类层次结构来判断它能做什么和不能做什么(不管它是如何做的)。由于多重继承的复杂性，一些能力的组合更难以用这种方式描述，而且c++以一种有点笨拙的方式支持仅接口继承(与java等相比)，但它确实存在(并且可以改进)。
然后模板开始发挥作用，还有STL。STL似乎采用了经典的OOP概念，并将它们冲入下水道，取而代之的是使用模板。
当模板用于泛化类型时，类型本身与模板的操作无关(例如容器)，这两种情况之间应该有区别。vector<int>非常有意义。
然而，在许多其他情况下(迭代器和算法)，模板化类型应该遵循一个“概念”(Input Iterator, Forward Iterator，等等)，其中概念的实际细节完全由模板函数/类的实现定义，而不是由模板使用的类型的类定义，这在某种程度上是对OOP的反使用。
例如，你可以告诉函数:
void MyFunc(ForwardIterator<...> *I);
更新:由于在最初的问题中不清楚，ForwardIterator本身可以被模板化以允许任何ForwardIterator类型。相反，将ForwardIterator作为一个概念。
只有通过查看它的定义才能期望Forward Iterator，在这里你需要查看以下方面的实现或文档:
template <typename Type> void MyFunc(Type *I);
我可以提出两个主张来支持使用模板:通过为每个使用的类型重新编译模板，而不是使用动态分派(主要通过虚表)，可以使编译后的代码更加高效。2. 事实上，模板可以与原生类型一起使用。
然而，我正在寻找一个更深刻的原因，放弃经典的面向对象的支持模板的STL?
我的理解是，Stroustrup最初更喜欢“oop风格”的容器设计，实际上也没有看到其他的方法。Alexander Stepanov是STL的负责人，他的目标并不包括“使它面向对象”:
That is the fundamental point: algorithms are defined on algebraic structures. It took me another couple of years to realize that you have to extend the notion of structure by adding complexity requirements to regular axioms. ... I believe that iterator theories are as central to Computer Science as theories of rings or Banach spaces are central to Mathematics. Every time I would look at an algorithm I would try to find a structure on which it is defined. So what I wanted to do was to describe algorithms generically. That's what I like to do. I can spend a month working on a well known algorithm trying to find its generic representation. ...
STL, at least for me, represents the only way programming is possible. It is, indeed, quite different from C++ programming as it was presented and still is presented in most textbooks. But, you see, I was not trying to program in C++, I was trying to find the right way to deal with software. ...
I had many false starts. For example, I spent years trying to find some use for inheritance and virtuals, before I understood why that mechanism was fundamentally flawed and should not be used. I am very happy that nobody could see all the intermediate steps - most of them were very silly.
(在接下来的采访中，他解释了为什么继承和虚拟——也就是面向对象的设计“从根本上存在缺陷，不应该被使用”)。
当Stepanov将他的库展示给Stroustrup时，Stroustrup和其他人付出了巨大的努力，将其纳入ISO c++标准(同一次采访):
The support of Bjarne Stroustrup was crucial. Bjarne really wanted STL in the standard and if Bjarne wants something, he gets it. ... He even forced me to make changes in STL that I would never make for anybody else ... he is the most single minded person I know. He gets things done. It took him a while to understand what STL was all about, but when he did, he was prepared to push it through. He also contributed to STL by standing up for the view that more than one way of programming was valid - against no end of flak and hype for more than a decade, and pursuing a combination of flexibility, efficiency, overloading, and type-safety in templates that made STL possible. I would like to state quite clearly that Bjarne is the preeminent language designer of my generation.
The short answer is "because C++ has moved on". Yes, back in the late 70's, Stroustrup intended to create an upgraded C with OOP capabilities, but that is a long time ago. By the time the language was standardized in 1998, it was no longer an OOP language. It was a multi-paradigm language. It certainly had some support for OOP code, but it also had a turing-complete template language overlaid, it allowed compile-time metaprogramming, and people had discovered generic programming. Suddenly, OOP just didn't seem all that important. Not when we can write simpler, more concise and more efficient code by using techniques available through templates and generic programming.
面向对象编程不是圣杯。这是一个可爱的想法，它比70年代的过程语言有了很大的改进。但说实话，它并不像人们说的那么好。在许多情况下，它是笨拙和冗长的，并不能真正促进可重用代码或模块化。
这就是为什么c++社区今天对泛型编程更感兴趣，也是为什么每个人终于开始意识到函数式编程也是相当聪明的。OOP本身并不是一个美丽的景象。
Try drawing a dependency graph of a hypothetical "OOP-ified" STL. How many classes would have to know about each other? There would be a lot of dependencies. Would you be able to include just the vector header, without also getting iterator or even iostream pulled in? The STL makes this easy. A vector knows about the iterator type it defines, and that's all. The STL algorithms know nothing. They don't even need to include an iterator header, even though they all accept iterators as parameters. Which is more modular then?
STL可能不像Java定义的那样遵循面向对象的规则，但它不也达到了面向对象的目标吗?难道它没有实现重用性、低耦合性、模块化和封装性吗?
它能比oop化的版本更好地实现这些目标吗?
至于为什么STL被采用到语言中，发生了几件事导致了STL的出现。
首先，将模板添加到c++中。添加它们的原因与。net中添加泛型的原因大致相同。能够在不抛弃类型安全性的情况下编写“T类型容器”之类的东西似乎是个好主意。当然，他们确定的实现要复杂得多，功能也强大得多。
然后人们发现他们添加的模板机制比预期的更强大。有人开始尝试使用模板来编写更通用的库。它受到函数式编程的启发，并且使用了c++的所有新功能。
他把它提交给c++语言委员会，委员会花了很长时间才适应它，因为它看起来很奇怪，很不一样，但最终意识到它比传统的面向对象编程更好。所以他们对它做了一些调整，并将其纳入标准库。
这不是一个意识形态的选择，也不是一个“我们想不想成为面向对象”的政治选择，而是一个非常务实的选择。他们评估了这个图书馆，发现它运行得很好。
在任何情况下，你提到的支持STL的两个原因都是绝对必要的。
c++标准库必须是高效的。如果它的效率低于，比如说，同等的手工编写的C代码，那么人们就不会使用它。这将降低生产力，增加bug的可能性，并且总体来说是个坏主意。
STL必须和原始类型一起工作，因为原始类型是C语言中所有的，它们是两种语言的主要部分。如果STL不能与本机数组一起工作，那么它将是无用的。
你的问题强烈地假设面向对象编程是“最好的”。我很好奇为什么。你问为什么他们“放弃了经典的面向对象编程”。我在想他们为什么要坚持下去。它会有哪些优势?
