为什么C ++ STL是如此大量基于模板？ （而不是*接口*） [英] Why is the C++ STL is so heavily based on templates? (and not on *interfaces*)
问题描述
我的意思是，除了它的义务名称（标准模板库）...
C ++最初旨在将COP概念呈现给C.也就是说：基于它的类和类层次结构来告诉什么特定的实体可以和不能做的（不管它是如何做的）。由于多重继承的问题，以及事实上C ++以稍微笨拙的方式支持接口的概念（与java等相比），但是它在那里（并且可以是改进）。
然后模板与STL一起发挥作用。 STL似乎采取了古典的OOP概念，并使用模板冲洗它们。
当模板用于泛化类型时，应该有区别类型自身与模板（例如容器）的操作无关。有一个向量是完美的意义。
然而，在许多其他情况下（迭代器和算法），模板类型应该遵循一个概念（Input Iterator，Forward Iterator ，etc ...），其中概念的实际细节完全由模板函数/类的实现来定义，而不是由模板使用的类型的类来定义，这是对OOP有点反对。 / p>
例如，你可以告诉函数：
void MyFunc ForwardIterator< ...> * I）;
更新：由于原始问题不清楚，ForwardIterator模板本身允许任何ForwardIterator类型。相反的是将ForwardIterator作为一个概念。
只需要查看一个Forward Iterator的定义，你需要查看实现或文档：
template< typename Type> void MyFunc（Type * I）;
两个声明我可以支持使用模板：编译代码可以更有效率， - 为每个使用的类型编译模板，而不是使用vtables。而且模板可以与原生类型一起使用。
然而，我在寻找一个更深刻的原因，为什么放弃古典OOP有利于STL的模板化？ （假设你阅读far：P）
简短的答案是因为C ++已经移动。是的，回到70年代末，Stroustrup打算创造一个升级的C与OOP功能，但这是很久以前。当语言在1998年标准化时，它不再是一种OOP语言。这是一个多范式语言。它肯定有一些支持OOP代码，但它也有一个图灵完整的模板语言覆盖，它允许编译时元编程，人们发现了通用编程。突然，OOP似乎没有那么重要。不是当我们可以使用通过模板和通用编程可用的技术编写更简单，更简洁的和更高效的代码。
OOP不是神圣的grail。这是一个可爱的想法，这是相对于过去的语言在70年代发明时的改进。但它的老实说，不是所有的破裂了。在许多情况下，它是笨拙和冗长，它不真正促进可重用的代码或模块化。
这就是为什么C ++社区今天更感兴趣的通用编程，为什么每个人都终于开始意识到，功能编程也很聪明。 OOP本身就不是一个漂亮的视线。
尝试绘制一个假设的OOP-ifiedSTL的依赖图。有多少类应该知道彼此？将有一个很多依赖。你能够只包括向量头，也不会得到迭代器或甚至 iostream 拉进来了？ STL使这很容易。向量知道它定义的迭代器类型，这就是所有。 STL算法知道没有。他们甚至不需要包含一个迭代器头，即使它们都接受迭代器作为参数。哪个更模块化呢？
STL可能不遵循OOP的规则，因为Java定义它，但是它不能实现OOP的目标它不会实现可重用性，低耦合，模块化和封装吗？
并不是比OOP-ified更好地实现这些目标版本会吗？
至于为什么STL被采用的语言，几个事情发生了导致STL。
首先，将模板添加到C ++。添加它们的原因与将泛型添加到.NET中的原因相同。似乎是一个好主意，能够写出像T型容器，而不会扔掉类型的安全。当然，他们确定的实现是非常复杂和强大的。
然后人们发现，他们添加的模板机制甚至比预期更强大。有人开始尝试使用模板来编写一个更通用的库。一个灵感来自函数式编程，另一个使用了C ++的所有新功能。
他将其提交给C ++语言委员会，他花了很长时间它因为它看起来很奇怪和不同，但最终意识到，它比传统的OOP等效，他们必须包括其他更好。因此，他们对它进行了一些调整，并将其纳入标准图书馆。
这不是一个意识形态的选择，它不是一个政治选择我们想成为OOP或不是，但一个非常务实的。他们评价了图书馆，看到它工作得很好。
在任何情况下，您提及的赞成STL的两个原因是绝对必要的。
标准库已高效。如果它比等效的手工滚动C代码效率低，那么人们就不会使用它。
而且STL 有可以处理原始类型，因为原始类型是你在C中拥有的，它们是这两种语言的主要部分。如果STL与本机数组不兼容，则无用。
您的问题有一个强烈的假设，即OOP是最好的。我很想知道为什么。你问为什么他们放弃古典OOP。我想知道为什么他们应该坚持下去。它会有哪些优势？
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).
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.
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 makes perfect sense.
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.
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.
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.
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)
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.
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.
That is why the C++ community is today far more interested in generic programming, and why everyone are finally starting to realize that functional programming is quite clever as well. OOP on its own just isn't a pretty sight.
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 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?
The STL may not follow the rules of OOP as Java defines it, but doesn't it achieve the goals of OOP? Doesn't it achieve reusability, low coupling, modularity and encapsulation?
And doesn't it achieve these goals better than an OOP-ified version would?
As for why the STL was adopted into the language, several things happened that led to the 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.
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++.
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.
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.
In any case, both of the reasons you mention for favoring the STL are absolutely essential.
The C++ standard library has to 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.
And the STL has to 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.
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?
这篇关于为什么C ++ STL是如此大量基于模板？ （而不是*接口*）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
