为什么 C++ STL 如此大量地基于模板？（而不是在*接口*上）

Why is the C++ STL is so heavily based on templates? (and not on *interfaces*)

提问by OB OB

I mean, aside from its obligating name (the Standard Template Library)...

我的意思是，除了它的强制性名称（标准模板库）...

C++ initially intended to present OOP concepts into C. That is: you could tell what a specific entity could and couldn't do (regardless of how it does it) based on its class and class hierarchy. Some compositions of abilities are more difficult to describe in this manner due to the problematics of multiple inheritance, and the fact that C++ supports the concept of interfaces in a somewhat clumsy way (compared to java, etc), but it's there (and could be improved).

C++ 最初打算将 OOP 概念呈现到 C 中。也就是说：您可以根据其类和类层次结构来判断特定实体可以做什么和不能做什么（无论它如何做）。由于多重继承的问题，以及 C++ 以某种笨拙的方式支持接口概念的事实（与 java 等相比），一些能力的组合更难以用这种方式描述，但它就在那里（并且可能是改进）。

And then templates came into play, along with the STL. The STL seemed to take the classical OOP concepts and flush them down the drain, using templates instead.

然后模板和 STL 一起发挥了作用。STL 似乎采用了经典的 OOP 概念并将它们冲入下水道，而是使用模板。

There should be a distinction between cases when templates are used to generalize types where the types themeselves are irrelevant for the operation of the template (containers, for examples). Having a vector<int>makes perfect sense.

当模板用于泛化类型时，类型本身与模板（例如容器）的操作无关的情况之间应该有区别。拥有一个vector<int>完美的意义。

However, in many other cases (iterators and algorithms), templated types are supposed to follow a "concept" (Input Iterator, Forward Iterator, etc...) where the actual details of the concept are defined entirely by the implementation of the template function/class, and not by the class of the type used with the template, which is a somewhat anti-usage of OOP.

然而，在许多其他情况下（迭代器和算法），模板化类型应该遵循一个“概念”（输入迭代器、前向迭代器等），其中概念的实际细节完全由模板的实现来定义函数/类，而不是与模板一起使用的类型的类，这在某种程度上是 OOP 的反用法。

For example, you can tell the function:

例如，您可以告诉函数：

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

Update:As it was unclear in the original question, ForwardIterator is ok to be templated itself to allow any ForwardIterator type. The contrary is having ForwardIterator as a concept.

更新：由于原始问题中不清楚， ForwardIterator 可以被模板化以允许任何 ForwardIterator 类型。相反，将 ForwardIterator 作为一个概念。

expects a Forward Iterator only by looking at its definition, where you'd need either to look at the implementation or the documentation for:

仅通过查看其定义来期望前向迭代器，您需要查看其实现或文档：

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

Two claims I can make in favor of using templates: compiled code can be made more efficient, by tailor-compiling the template for each used type, instead of using vtables. And the fact that templates can be used with native types.

我可以提出两个支持使用模板的声明：通过为每个使用的类型定制编译模板，而不是使用 vtables，可以使编译后的代码更有效率。以及模板可以与本机类型一起使用的事实。

However, I am looking for a more profound reason why abandoning classical OOP in favor of templating for the STL? (Assuming you read that far :P)

但是，我正在寻找一个更深刻的原因，为什么放弃经典的 OOP 而支持 STL 的模板？（假设你读了那么远：P）

回答by jalf

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 andmore efficient code by using techniques available through templates and generic programming.

简短的回答是“因为 C++ 已经向前发展了”。是的，早在 70 年代后期，Stroustrup 就打算创建具有 OOP 功能的升级版 C，但那是很久以前的事了。到 1998 年该语言标准化时，它已不再是 OOP 语言。它是一种多范式语言。它当然支持 OOP 代码，但它也覆盖了图灵完备的模板语言，允许编译时元编程，人们发现了泛型编程。突然之间，OOP 似乎不再那么重要了。当我们可以通过使用模板和泛型编程提供的技术编写更简单、更简洁和更高效的代码时，情况并非如此。

OOP is not the holy grail. It's a cute idea, and it was quite an improvement over procedural languages back in the 70's when it was invented. But it's honestly not all it's cracked up to be. In many cases it is clumsy and verbose and it doesn't really promote reusable code or modularity.

OOP 不是圣杯。这是一个可爱的想法，它比 20 世纪 70 年代发明的过程语言有了很大的改进。但老实说，这并不是它被破解的全部。在许多情况下，它笨拙而冗长，并没有真正促进可重用代码或模块化。

That is why the C++ community is today far more interested in generic programming, and why everyoneare finally starting to realize that functional programming is quite clever as well. OOP on its own just isn't a pretty sight.

这就是今天 C++ 社区对泛型编程更感兴趣的原因，也是为什么每个人终于开始意识到函数式编程也非常聪明的原因。OOP 本身并不是一个美丽的景象。

Try drawing a dependency graph of a hypothetical "OOP-ified" STL. How many classes would have to know about each others? There would be a lotof dependencies. Would you be able to include just the vectorheader, without also getting iteratoror even iostreampulled 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?

尝试绘制一个假设的“OOP 化”STL 的依赖图。有多少班级必须相互了解？会有很多依赖。您是否能够只包含vector标题，而不会被插入iterator甚至iostream被拉入？STL 使这变得容易。向量知道它定义的迭代器类型，仅此而已。STL 算法一无所知。它们甚至不需要包含迭代器头，即使它们都接受迭代器作为参数。哪个更模块化？

The STL may not follow the rules of OOP as Java defines it, but doesn't it achieve the goalsof OOP? Doesn't it achieve reusability, low coupling, modularity and encapsulation?

STL 可能不遵循Java 定义的OOP 规则，但它是否达到了OOP的目标？不是实现了复用性、低耦合性、模块化和封装性吗？

And doesn't it achieve these goals betterthan an OOP-ified version would?

它不是比 OOP 化版本更好地实现这些目标吗？

As for why the STL was adopted into the language, several things happened that led to the STL.

至于为什么 STL 被采用到语言中，发生了几件事导致了 STL。

First, templates were added to C++. They were added for much the same reason that generics were added to .NET. It seemed a good idea to be able to write stuff like "containers of a type T" without throwing away type safety. Of course, the implementation they settled on was quite a lot more complex and powerful.

首先，模板被添加到 C++ 中。添加它们的原因与将泛型添加到 .NET 的原因大致相同。能够在不丢弃类型安全的情况下编写诸如“T 类型的容器”之类的东西似乎是一个好主意。当然，他们确定的实现要复杂得多，而且功能强大得多。

Then people discovered that the template mechanism they had added was even more powerful than expected. And someone started experimenting with using templates to write a more generic library. One inspired by functional programming, and one which used all the new capabilities of C++.

然后人们发现他们添加的模板机制比预期的更强大。有人开始尝试使用模板来编写更通用的库。一种受函数式编程启发，另一种使用 C++ 的所有新功能。

He presented it to the C++ language committee, who took quite a while to grow used to it because it looked so strange and different, but ultimately realized that it worked better than the traditional OOP equivalents they'd have to include otherwise. So they made a few adjustments to it, and adopted it into the standard library.

他将它提交给 C++ 语言委员会，后者花了很长时间才习惯它，因为它看起来如此奇怪和不同，但最终意识到它比他们必须包含的传统 OOP 等价物更有效。所以他们对其进行了一些调整，并将其纳入标准库。

It wasn't an ideological choice, it wasn't a political choice of "do we want to be OOP or not", but a very pragmatic one. They evaluated the library, and saw that it worked very well.

这不是意识形态的选择，也不是“我们要不要OOP”的选择，而是一个非常务实的选择。他们评估了这个库，发现它运行良好。

In any case, both of the reasons you mention for favoring the STL are absolutely essential.

无论如何，您提到的支持 STL 的两个原因都是绝对必要的。

The C++ standard library hasto be efficient. If it is less efficient than, say, the equivalent hand-rolled C code, then people would not use it. That would lower productivity, increase the likelihood of bugs, and overall just be a bad idea.

C++ 标准库必须是高效的。如果它比等效的手动 C 代码效率低，那么人们就不会使用它。这会降低生产力，增加出现错误的可能性，并且总体而言只是一个坏主意。

And the STL hasto work with primitive types, because primitive types are all you have in C, and they're a major part of both languages. If the STL did not work with native arrays, it would be useless.

STL必须使用原始类型，因为原始类型是 C 中的全部，并且它们是两种语言的主要部分。如果 STL 不适用于本机数组，它将毫无用处。

Your question has a strong assumption that OOP is "best". I'm curious to hear why. You ask why they "abandoned classical OOP". I'm wondering why they should have stuck with it. Which advantages would it have had?

您的问题有一个强有力的假设，即 OOP 是“最好的”。我很想知道为什么。你问他们为什么“放弃经典的 OOP”。我想知道为什么他们应该坚持下去。它有哪些优势？

回答by Tyler McHenry

The most direct answer to what I think you're asking/complaining about is this: The assumption that C++ is an OOP language is a false assumption.

我认为您要问/抱怨的最直接的答案是：假设 C++ 是一种 OOP 语言是错误的假设。

C++ is a multi-paradigm language. It can be programmed using OOP principles, it can be programmed procedurally, it can be programmed generically (templates), and with C++11 (formerly known as C++0x) some things can even be programmed functionally.

C++ 是一种多范式语言。它可以使用 OOP 原则进行编程，可以通过程序进行编程，可以进行泛型编程（模板），并且使用 C++11（以前称为 C++0x）甚至可以对某些东西进行功能性编程。

The designers of C++ see this as an advantage, so they would argue that constraining C++ to act like a purely OOP language when generic programming solves the problem better and, well, more generically, would be a step backwards.

C++ 的设计者认为这是一个优势，所以他们会争辩说，当泛型编程更好地解决问题时，将 C++ 限制为像纯粹的 OOP 语言一样，而且，更通用地，将是一种倒退。

回答by Max Lybbert

My understanding is that Stroustrup originally preferred an "OOP-styled" container design, and in fact didn't see any other way to do it. Alexander Stepanov is the one responsible for the STL, and his goals did not include "make it object oriented":

我的理解是 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.

这是基本点：算法是在代数结构上定义的。我又花了几年时间才意识到必须通过向常规公理添加复杂性要求来扩展结构的概念。...我相信迭代器理论对于计算机科学的重要性就像环或巴拿赫空间理论对于数学的重要性一样。每次我查看算法时，我都会尝试找到定义它的结构。所以我想做的是一般性地描述算法。这就是我喜欢做的。我可以花一个月的时间研究一个著名的算法，试图找到它的通用表示。...

STL，至少对我来说，代表了唯一的编程方式。事实上，它与 C++ 编程大不相同，因为它在大多数教科书中已经出现并且仍然存在。但是，你看，我并不是想用 C++ 编程，我是想找到处理软件的正确方法。...

我有很多错误的开始。例如，我花了数年时间试图找到继承和虚拟的一些用途，然后才明白为什么这种机制存在根本性的缺陷，不应该使用。我很高兴没有人能看到所有的中间步骤 - 其中大部分都非常愚蠢。

(He does explain why inheritance and virtuals -- a.k.a. object oriented design "was fundamentally flawed and should not be used" in the rest of the interview).

（他确实在采访的其余部分解释了为什么继承和虚拟——也就是面向对象的设计“从根本上有缺陷，不应该使用”）。

Once Stepanov presented his library to Stroustrup, Stroustrup and others went through herculean efforts to get it into the ISO C++ standard (same interview):

一旦 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.

Bjarne Stroustrup 的支持至关重要。Bjarne 真的想要标准中的 STL，如果 Bjarne 想要什么，他就会得到。......他甚至强迫我在 STL 中做出我永远不会为其他人做出的改变......他是我认识的最专一的人。他把事情做好。他花了一段时间才明白 STL 是什么意思，但当他明白时，他已经准备好推动它了。他还通过支持不止一种编程方式有效的观点为 STL 做出了贡献——十多年来，他一直在不断地抨击和炒作，并追求灵活性、效率、重载和类型安全的结合。使 STL 成为可能的模板。我想非常清楚地说明，Bjarne 是我们这一代杰出的语言设计者。

回答by StackedCrooked

The answer is found in this interviewwith Stepanov, the author of the STL:

在对 STL 的作者 Stepanov 的采访中可以找到答案：

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people.

是的。STL 不是面向对象的。我认为面向对象几乎和人工智能一样都是骗局。我还没有看到来自这些面向对象的人的一段有趣的代码。

回答by AraK

Why a pure OOP design to a Data Structure & Algorithms Library would be better ?! OOP is not the solution for every thing.

为什么数据结构和算法库的纯 OOP 设计会更好？！OOP 并不是所有事情的解决方案。

IMHO, STL is the most elegant library I have seen ever :)

恕我直言，STL 是我见过的最优雅的库 :)

for your question,

对于你的问题，

you don't need runtime polymorphism, it is an advantage for STL actually to implement the Library using static polymorphism, that means efficiency. Try to write a generic Sort or Distance or what ever algorithm that applies to ALL containers! your Sort in Java would call functions that are dynamic through n-levels to be executed!

您不需要运行时多态性，实际上使用静态多态性来实现库对 STL 来说是一个优势，这意味着效率。尝试编写适用于所有容器的通用排序或距离或任何算法！您在 Java 中的排序将调用通过 n 级动态执行的函数！

You need stupid thing like Boxing and Unboxing to hide nasty assumptions of the so called Pure OOP languages.

你需要像装箱和拆箱这样愚蠢的东西来隐藏所谓的纯 OOP 语言的令人讨厌的假设。

The only problem I see with STL, and templates in general is the awful error messages. Which will be solved using Concepts in C++0X.

我在 STL 和模板中看到的唯一问题是糟糕的错误消息。这将使用 C++0X 中的概念解决。

Comparing STL to Collections in Java is Like comparing Taj Mahal to my house :)

将 STL 与 Java 中的集合进行比较就像将泰姬陵与我的房子进行比较：)

回答by Steve Jessop

templated types are supposed to follow a "concept" (Input Iterator, Forward Iterator, etc...) where the actual details of the concept are defined entirely by the implementation of the template function/class, and not by the class of the type used with the template, which is a somewhat anti-usage of OOP.

模板化类型应该遵循一个“概念”（输入迭代器、前向迭代器等...），其中概念的实际细节完全由模板函数/类的实现定义，而不是由类型的类定义与模板一起使用，这在某种程度上是 OOP 的反用法。

I think you misunderstand the intended use of concepts by templates. Forward Iterator, for example, is a very well-defined concept. To find the expressions which must be valid in order for a class to be a Forward Iterator, and their semantics including computational complexity, you look at the standard or at http://www.sgi.com/tech/stl/ForwardIterator.html(you have to follow the links to Input, Output, and Trivial Iterator to see it all).

我认为您误解了模板对概念的预期用途。例如，前向迭代器是一个非常明确的概念。要找到使类成为前向迭代器必须有效的表达式，以及它们的语义（包括计算复杂性），请查看标准或http://www.sgi.com/tech/stl/ForwardIterator.html（您必须按照 Input、Output 和 Trivial Iterator 的链接查看所有内容）。

That document is a perfectly good interface, and "the actual details of the concept" are defined right there. They are not defined by the implementations of Forward Iterators, and neither are they defined by the algorithms which use Forward Iterators.

该文档是一个非常好的界面，“概念的实际细节”就在那里定义。它们不是由前向迭代器的实现定义的，也不是由使用前向迭代器的算法定义的。

The differences in how interfaces are handled between STL and Java are three-fold:

STL 和 Java 之间在接口处理方式上的差异有三方面：

1) STL defines valid expressions using the object, whereas Java defines methods which must be callable on the object. Of course a valid expression might be a method (member function) call, but it doesn't have to be.

1) STL 定义使用对象的有效表达式，而 Java 定义必须可在对象上调用的方法。当然，有效的表达式可能是方法（成员函数）调用，但并非必须如此。

2) Java interfaces are runtime objects, whereas STL concepts are not visible at runtime even with RTTI.

2) Java 接口是运行时对象，而 STL 概念在运行时即使使用 RTTI 也不可见。

3) If you fail to make valid the required valid expressions for an STL concept, you get an unspecified compilation error when you instantiate some template with the type. If you fail to implement a required method of a Java interface, you get a specific compilation error saying so.

3) 如果您未能使 STL 概念所需的有效表达式有效，则当您使用该类型实例化某个模板时，您会收到未指定的编译错误。如果您未能实现 Java 接口的必需方法，您会收到一个特定的编译错误。

This third part is if you like a kind of (compile-time) "duck typing": interfaces can be implicit. In Java, interfaces are somewhat explicit: a class "is" Iterable if and only if it saysit implements Iterable. The compiler can check that the signatures of its methods are all present and correct, but the semantics are still implicit (i.e. they're either documented or not, but only more code (unit tests) can tell you whether the implementation is correct).

这第三部分是如果你喜欢一种（编译时）“鸭子类型”：接口可以是隐式的。在 Java 中，接口有些明确：一个类“是” Iterable 当且仅当它说它实现了 Iterable。编译器可以检查其方法的签名是否都存在且正确，但语义仍然是隐式的（即它们要么被记录在案，要么没有，但只有更多的代码（单元测试）可以告诉你实现是否正确）。

In C++, like in Python, both semantics and syntax are implicit, although in C++ (and in Python if you get the strong-typing preprocessor) you do get some help from the compiler. If a programmer requires Java-like explicit declaration of interfaces by the implementing class, then the standard approach is to use type traits (and multiple inheritance can prevent this being too verbose). What's lacking, compared with Java, is a single template which I can instantiate with my type, and which will compile if and only if all the required expressions are valid for my type. This would tell me whether I've implemented all the required bits, "before I use it". That's a convenience, but it's not the core of OOP (and it still doesn't test semantics, and code to test semantics would naturally also test the validity of the expressions in question).

在 C++ 中，就像在 Python 中一样，语义和语法都是隐式的，尽管在 C++ 中（以及在 Python 中，如果您获得了强类型预处理器），您确实可以从编译器那里获得一些帮助。如果程序员需要实现类对接口进行类似 Java 的显式声明，那么标准方法是使用类型特征（并且多重继承可以防止这种情况过于冗长）。与 Java 相比，缺少的是我可以用我的类型实例化的单个模板，并且当且仅当所有必需的表达式对我的类型都有效时，它才会编译。这将告诉我“在使用它之前”是否已经实现了所有必需的位。这很方便，但它不是 OOP 的核心（而且它仍然不测试语义，

STL may or may not be sufficiently OO for your taste, but it certainly separates interface cleanly from implementation. It does lack Java's ability to do reflection over interfaces, and it reports breaches of interface requirements differently.

STL 可能是也可能不是您喜欢的 OO，但它确实将接口与实现完全分开。它确实缺乏 Java 对接口进行反射的能力，并且它以不同的方式报告违反接口要求的情况。

you can tell the function ... expects a Forward Iterator only by looking at its definition, where you'd need either to look at the implementation or the documentation for ...

你可以告诉函数......只通过查看它的定义来期望一个前向迭代器，你需要查看它的实现或文档......

Personally I think that implicit types are a strength, when used appropriately. The algorithm says what it does with its template parameters, and the implementer makes sure those things work: it's exactly the common denominator of what "interfaces" should do. Furthermore with STL, you're unlikely to be using, say, std::copybased on finding its forward declaration in a header file. Programmers shouldbe working out what a function takes based on its documentation, not just on the function signature. This is true in C++, Python, or Java. There are limitations on what can be achieved with typing in any language, and trying to use typing to do something it doesn't do (check semantics) would be an error.

我个人认为，如果使用得当，隐式类型是一种优势。算法说明它用模板参数做什么，实现者确保这些东西起作用：这正是“接口”应该做什么的公分母。此外，使用 STL，您不太可能使用，例如，std::copy基于在头文件中找到它的前向声明。程序员应该根据函数的文档，而不仅仅是函数签名来确定函数需要做什么。这在 C++、Python 或 Java 中是正确的。用任何语言打字所能达到的效果是有限制的，尝试使用打字来做它不做的事情（检查语义）将是一个错误。

That said, STL algorithms usually name their template parameters in a way which makes it clear what concept is required. However this is to provide useful extra information in the first line of the documentation, not to make forward declarations more informative. There are more things you need to know than can be encapsulated in the types of the parameters, so you have to read the docs. (For example in algorithms which take an input range and an output iterator, chances are the output iterator needs enough "space" for a certain number of outputs based on the size of the input range and maybe the values therein. Try strongly typing that.)

也就是说，STL 算法通常以一种明确需要什么概念的方式命名它们的模板参数。然而，这是为了在文档的第一行提供有用的额外信息，而不是为了使前向声明提供更多信息。您需要了解的内容比可以封装在参数类型中的要多，因此您必须阅读文档。（例如，在采用输入范围和输出迭代器的算法中，根据输入范围的大小和其中的值，输出迭代器可能需要足够的“空间”用于一定数量的输出。尝试强输入。 )

Here's Bjarne on explicitly-declared interfaces: http://www.artima.com/cppsource/cpp0xP.html

这是 Bjarne 关于显式声明的接口：http: //www.artima.com/cppsource/cpp0xP.html

In generics, an argument must be of a class derived from an interface (the C++ equivalent to interface is abstract class) specified in the definition of the generic. That means that all generic argument types must fit into a hierarchy. That imposes unnecessary constraints on designs requires unreasonable foresight on the part of developers. For example, if you write a generic and I define a class, people can't use my class as an argument to your generic unless I knew about the interface you specified and had derived my class from it. That's rigid.

在泛型中，参数必须是从泛型定义中指定的接口派生的类（与接口等效的 C++ 是抽象类）。这意味着所有泛型参数类型都必须适合层次结构。这对设计施加了不必要的限制，要求开发人员具有不合理的远见。例如，如果您编写一个泛型并且我定义了一个类，除非我知道您指定的接口并从中派生出我的类，否则人们不能将我的类用作泛型的参数。那是刚性的。

Looking at it the other way around, with duck typing you can implement an interface without knowing that the interface exists. Or someone can write an interface deliberately such that your class implements it, having consulted your docs to see that they don't ask for anything you don't already do. That's flexible.

反过来看，使用鸭子类型，您可以在不知道接口存在的情况下实现接口。或者有人可以故意编写一个接口，以便您的类实现它，查阅您的文档以了解他们不会要求您尚未做的任何事情。那是灵活的。

回答by Ben Hughes

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." - Alan Kay, creator of Smalltalk.

“对我而言，OOP 仅意味着消息传递、本地保留和保护以及状态过程的隐藏，以及所有事物的极端后期绑定。它可以在 Smalltalk 和 LISP 中完成。可能还有其他系统可以做到这一点，但是我不知道他们。” -Alan Kay，Smalltalk 的创造者。

C++, Java, and most other languages are all pretty far from classical OOP. That said, arguing for ideologies is not terribly productive. C++ is not pure in any sense, so it implements functionality that seems to make pragmatic sense at the time.

C++、Java 和大多数其他语言都与经典的 OOP 相去甚远。话虽如此，为意识形态争论并不十分有效。C++ 在任何意义上都不是纯粹的，因此它实现了在当时似乎具有实用意义的功能。

回答by yowkee

STL started off with the intention of provide a large library covering most commonly used algorithm -- with the target of consitent behavior and performance. Template came as a key factor to make that implementation and target feasible.

STL 开始的目的是提供一个涵盖最常用算法的大型库——以一致的行为和性能为目标。模板是使实施和目标可行的关键因素。

Just to provide another reference:

只是提供另一个参考：

Al Stevens Interviews Alex Stepanov, in March 1995 of DDJ:

1995 年 3 月，Al Stevens 采访了亚历克斯 Stepanov，DDJ：

• http://www.sgi.com/tech/stl/drdobbs-interview.html

• http://www.sgi.com/tech/stl/drdobbs-interview.html

Stepanov explained his work experience and choice made towards a large library of algorithm, which eventually evolved into STL.

Stepanov 解释了他的工作经验和对大型算法库的选择，最终演变为 STL。

Tell us something about your long-term interest in generic programming

.....Then I was offered a job at Bell Laboratories working in the C++ group on C++ libraries. They asked me whether I could do it in C++. Of course, I didn't know C++ and, of course, I said I could. But I couldn't do it in C++, because in 1987 C++ didn't have templates, which are essential for enabling this style of programming. Inheritance was the only mechanism to obtain genericity and it was not sufficient.

Even now C++ inheritance is not of much use for generic programming. Let's discuss why. Many people have attempted to use inheritance to implement data structures and container classes. As we know now, there were few if any successful attempts. C++ inheritance, and the programming style associated with it are dramatically limited. It is impossible to implement a design which includes as trivial a thing as equality using it. If you start with a base class X at the root of your hierarchy and define a virtual equality operator on this class which takes an argument of the type X, then derive class Y from class X. What is the interface of the equality? It has equality which compares Y with X. Using animals as an example (OO people love animals), define mammal and derive giraffe from mammal. Then define a member function mate, where animal mates with animal and returns an animal. Then you derive giraffe from animal and, of course, it has a function mate where giraffe mates with animal and returns an animal. It's definitely not what you want. While mating may not be very important for C++ programmers, equality is. I do not know a single algorithm where equality of some kind is not used.

告诉我们您对泛型编程的长期兴趣

.....然后我在贝尔实验室获得了一份工作，在 C++ 组的 C++ 库工作。他们问我是否可以用 C++ 来做。当然，我不知道 C++，当然，我说我可以。但是我不能在 C++ 中做到这一点，因为在 1987 年 C++ 没有模板，而模板对于启用这种编程风格是必不可少的。继承是获得通用性的唯一机制，而且还不够。

即使是现在，C++ 继承对于泛型编程也没有多大用处。让我们来讨论为什么。许多人尝试使用继承来实现数据结构和容器类。正如我们现在所知，成功的尝试很少。C++ 继承以及与之相关的编程风格非常有限。不可能实现一个设计，其中包括使用它的平等等微不足道的事情。如果您从层次结构根的基类 X 开始，并在这个类上定义一个虚拟相等运算符，它接受类型 X 的参数，然后从类 X 派生类 Y。相等的接口是什么？它具有将 Y 与 X 进行比较的相等性。以动物为例（OO 人们喜欢动物），定义哺乳动物并从哺乳动物衍生出长颈鹿。然后定义一个成员函数mate，动物与动物交配并返回动物。然后你从动物派生出长颈鹿，当然，它有一个功能 mate，长颈鹿与动物交配并返回一个动物。这绝对不是你想要的。虽然配对对 C++ 程序员来说可能不是很重要，但平等才是。我不知道不使用某种相等性的单一算法。

回答by yowkee

The basic problem with

基本问题

void MyFunc(ForwardIterator *I);

is how do you safely get the type of the thing the iterator returns? With templates, this is done for you at compile time.

是如何安全地获得迭代器返回的事物的类型？使用模板，这是在编译时为您完成的。

回答by Jerry Coffin

For a moment, let's think of the standard library as basically a database of collections and algorithms.

暂时，让我们将标准库视为基本上是集合和算法的数据库。

If you've studied the history of databases, you undoubtedly know that back in the beginning, databases were mostly "hierarchical". Hierarchical databases corresponded very closely to classical OOP--specifically, the single-inheritance variety, such as used by Smalltalk.

如果您研究过数据库的历史，您无疑会知道，一开始，数据库大多是“分层的”。分层数据库与经典的 OOP 非常接近——特别是单继承类型，例如 Smalltalk 使用的。

Over time, it became apparent that hierarchical databases could be used to model almost anything, butin some cases the single-inheritance model was fairly limiting. If you had a wooden door, it was handy to be able to look at it either as a door, or as a piece of some raw material (steel, wood, etc.)

随着时间的推移，分层数据库几乎可以用来建模任何东西变得很明显，但在某些情况下，单继承模型是相当有限的。如果您有一个木门，可以很方便地将其视为门，或将其视为某些原材料（钢、木材等）的碎片。

So, they invented network model databases. Network model databases correspond very closely to multiple inheritance. C++ supports multiple inheritance completely, while Java supports a limited form (you can inherit from only one class, but can also implement as many interfaces as you like).

因此，他们发明了网络模型数据库。网络模型数据库非常接近于多重继承。C++完全支持多重继承，而Java支持的形式有限（可以只继承一个类，也可以实现任意多个接口）。

Both hierarchical model and network model databases have mostly faded from general purpose use (though a few remain in fairly specific niches). For most purposes, they've been replaced by relational databases.

层次模型和网络模型数据库大多已从通用用途中消失（尽管有一些仍处于相当特定的领域）。在大多数情况下，它们已被关系数据库取代。

Much of the reason relational databases took over was versatility. The relational model is functionally a superset of the network model (which is, in turn, a superset of the hierarchical model).

关系数据库接管的大部分原因是多功能性。关系模型在功能上是网络模型的超集（它又是层次模型的超集）。

C++ has largely followed the same path. The correspondence between single inheritance and the hierarchical model and between multiple inheritance and the network model are fairly obvious. The correspondence between C++ templates and the hierarchical model may be less obvious, but it's a pretty close fit anyway.

C++ 在很大程度上遵循了相同的路径。单继承与层次模型、多继承与网络模型的对应关系是比较明显的。C++ 模板和层次模型之间的对应关系可能不太明显，但无论如何它是非常接近的。

I haven't seen a formal proof of it, but I believe the capabilities of templates are a superset of those provided by multiple inheritance (which is clearly a superset of single inerhitance). The one tricky part is that templates are mostly statically bound--that is, all the binding happens at compile time, not run time. As such, a formal proof that inheritance provides a superset of the capabilities of inheritance may well be somewhat difficult and complex (or may even be impossible).

我还没有看到它的正式证明，但我相信模板的功能是多重继承提供的功能的超集（这显然是单继承的超集）。一个棘手的部分是模板大多是静态绑定的——也就是说，所有绑定都发生在编译时，而不是运行时。因此，正式证明继承提供了继承能力的超集可能有些困难和复杂（甚至可能是不可能的）。

In any case, I think that's most of the real reason C++ doesn't use inheritance for its containers--there's no real reason to do so, because inheritance provides only a subset of the capabilities provided by templates. Since templates are basically a necessity in some cases, they might as well be used nearly everywhere.

无论如何，我认为这是 C++ 不对其容器使用继承的大部分真正原因——没有真正的理由这样做，因为继承仅提供了模板提供的功能的一个子集。由于模板在某些情况下基本上是必需的，因此它们几乎可以在任何地方使用。