我的意思是,除了它的名字标准模板库(后来演变成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?


当前回答

对于我认为你在问或抱怨的问题,最直接的回答是:假设c++是一种面向对象语言是一个错误的假设。

c++是一种多范式语言。它可以使用面向对象原则编程,可以程序化编程,也可以泛型编程(模板),使用c++ 11(以前称为c++ 0x)甚至可以对某些东西进行函数式编程。

c++的设计者认为这是一种优势,所以他们会争辩说,当泛型编程能更好地解决问题,并且更通用地解决问题时,限制c++像纯粹的面向对象语言一样运行将是一种倒退。

其他回答

对于我认为你在问或抱怨的问题,最直接的回答是:假设c++是一种面向对象语言是一个错误的假设。

c++是一种多范式语言。它可以使用面向对象原则编程,可以程序化编程,也可以泛型编程(模板),使用c++ 11(以前称为c++ 0x)甚至可以对某些东西进行函数式编程。

c++的设计者认为这是一种优势,所以他们会争辩说,当泛型编程能更好地解决问题,并且更通用地解决问题时,限制c++像纯粹的面向对象语言一样运行将是一种倒退。

为什么数据结构和算法库的纯面向对象设计会更好?! 面向对象编程并不是所有事情的解决方案。

恕我直言,STL是我见过的最优雅的图书馆:)

关于你的问题,

你不需要运行时多态性,STL实际上使用静态多态性实现库是一个优势,这意味着效率。 试着写一个通用的Sort或Distance或任何适用于所有容器的算法! 你在Java中的Sort会调用动态的n级函数来执行!

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

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

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

最基本的问题是

void MyFunc(ForwardIterator *I);

你如何安全地获取迭代器返回的东西的类型?对于模板,这是在编译时为您完成的。

如何与ForwardIterator*进行比较?也就是说,你如何检查你所拥有的物品是否是你正在寻找的,或者你已经错过了它?

大多数时候,我会使用这样的方法:

void MyFunc(ForwardIterator<MyType>& i)

这意味着我知道I指向MyType的,我知道如何比较它们。虽然它看起来像一个模板,但实际上不是(没有“template”关键字)。

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