Developpeur Reference对Bjarne Stroustrup的采访(转载)

1.C++的ANSI/ISO标准化过程时间很长，直到1998年才完成。对于没能在更短的时间内完成该项工作，您感到遗憾吗？

您认为这减缓了C++的“渗透”吗（举个例子，在教育领域，许多人继续教授C语言，并声称C++还没有被标准化，这种境况真让人恼火）？ 

您认为这减缓了C++的进化了吗（标准库的更好的进化，对分布式计算的考虑……）？ 

Bjarne Stroustrup：当然了，假如C++标准能够更早地完成，情况会很好，但实际上C++标准化过程并不比其他标准来得慢。正儿八经的标准化所需的时间，要比大多数人所想象的时间长，因为要满足那么多人和组织的要求。 

许多人过去 — 一些人现在 — 还这么教学：要么把C+ +当成一种非常低级的语言，集中于“和C共享”的那些特性上，或者把它当作一种表达类层次结构的语言。两种方式都没有突出C++最伟大的力量。更糟糕的 是，这些方式通常在那些“对程序员帮助不太大”的C++组成部分上花费太多的时间，而未能教授关键的技术和语言设施，以利于更有效地使用C++。标准库里 的容器和算法，以及用于资源管理的异常（exceptions）的使用，就是一些常常被忽视的“关键的主题”的例子，或被错误地认为过于“高级”。 

我认为，与漫长的ISO标准化过程相比，这种教学上的失败对C++的应用所造成的伤害更大。显然，假如在1985年我们就有标准库可用的话，情况会好很多，但事实并非如此。如此一来，我们也就不知道该怎么来设计和实现一些通用、优雅和高效的东西。 

听到有人说C++还没有被标准化，真让人感到悲哀。1998年ISO标准被批准，其实自1996年起，就没有向语言或标准库中添加新的重大特性了，在计算领域，这个时间可不短。 

至于进化的速度，它受限于我们对问题的理解，尤其被我们的教学能力（教授“很好地使用这种语言”的能力）所限。我不认为语言能够或者应该比现在这个样子进化速度快很多。实验性的语言可以迅速演化，因为它们几乎没有什么用户，而象C++这样的主流语言，不能比它的用户社群变化得还快，“稳定压倒一切”。

2.对于C++接下来的版本，好像您更倾向于扩展标准库而不是进化语言的语法。可以解释一下您的立场吗？ 

您希望看到哪方面的库被标准化：多线程？分布式计算？打算走得象Java那样远吗 — 提供一个针对GUI的标准库？ 

Bjarne Stroustrup：我的提议是，ISO C++标准的下一次修订工作要集中于标准库上。语言已经足够强大有力，可以表达绝大多数我们要表达的东西，保持稳定则至关重要。因此，对于语言的扩充，我 们应该小心谨慎，将精力放在通用性和有助于教学的东西上，而不要添加什么大的新特性。而在另一方面，对于标准库的扩充，我们应该把握时机，积极进取。 

我认为，就象“工具”之于“系统开发”一样，“库”使C++变得更好。资源管理、线程、物理上的分布式机制以及TCP/IP等，都是显而易见的候选者。我们也几乎肯定会寻找象hash_maps和模式匹配（pattern matching）这样的有意义的工具。我担心GUI对于标准委员会来说太过复杂并且是一个太易引起争议的主题。委员会由志愿者组成，我们没有足够的资源来创建一个大型GUI库。还有，标准委员会不能跟商业（和非商业）供应者竞争，它必须努力服务于整个社群。 

3.Linux和开放源码社群并没有真的欢迎C++，大多数开发者依然使用C语言，有些人声称因为C语言具有性能上的优势（比如Linux内核），还有一些人“从头发明轮子”，在C语言里重新实现了一个对象层，对此，您怎么看？

您认为KDE（使用C++编写而成）的成功，以及它的开发速度，与Gnome（使用C编写而成）的迟钝的对比，例证了C++的优越之处吗？您还能给出一些别的例子吗？ 

Bjarne Stroustrup：我认为“重新发明轮子”是愚蠢的行为，“过于使用C”则表明“对C++能为系统构建者提供什么”无知。这是我们领域不成熟的象征：人们抵制采用更为高级的工具，并喜欢将精力花到“使用原始工具重新发明轮子”上，而不愿意花时间来学习更具威力的工具。 

4.在许多程序员的意识里，尤其是Java程序员，C++仍然是“C语言面向对象的版本”，您怎么来说服他们C++不仅如此呢？ 

Bjarne Stroustrup：想去说服那些不愿意被说服的人，是很困难的。 

     #include<string>
     #include<vector>
     #include<iostream>
     #include<algorithm>
     using namespace std;

     int main()
     {
         vector<string> v;
         string s;
         while (cin>>s) v.push_back(s);          // read a file of words
         sort(v.begin(),v.end());                // sort the words
         ostream_iterator<string> os(cout,"\n");
         unique_copy(v.begin(),v.end(),os);      // output unique words
     } 

把这个例子用C语言写一遍，再比比看，并请确保不要带来“缓冲区溢出”或“内存泄漏”问题。 

5.在 对一个关于C#的问题的回答中，您说过，它是一门私有语言，用在一个私有平台上。但C#已经被ECMA标准化了，并正进入ISO标准化进程，并且，我们也 可以看到一些针对其他平台的实现品（比如Linux上的Mono）。假如有朝一日C#变成了ISO标准，您会改变主意吗？

Bjarne Stroustrup：可能不会，并且我认为那不可能。我仔细观察了标准化过程，以便了解是否真的已经有许多感兴趣的团体投入其中，并且该语言的演化不是在一家公司的掌控之下。严格意义上的标准化过程，并不仅仅是产生一纸批文。

6.C#和Java一样，采取单继承方式，这和C++不一样，后者实现了多继承。您认为多继承一向是最佳解决方案吗？ 

Bjarne Stroustrup：多继承并非一向都是最佳方案，但有时问题的最佳解决方案涉及多继承技术。请注意，甚至Java也包括多继承的一个受限的形式：接口的继承。有了多继承，我感到很舒服，并且在我看来，假如没有多继承的话，许多问题不能优雅地予以解决。在我的《The C++ Programming Language》一书中，此类例子超过一打。一个关键的技术是分别继承一个接口（通常是一个抽象类）和一个“部分实现品”。 

你总是可以将一个使用了多继承的例子，改写为只使用单继承（通过使用转递函数（forwarding functions））。然而，结果通常是一个更冗长的、更不能直接反映设计的并且更难维护的的例子。注意，你还可以采用同样的办法，将每一个使用单继承 的例子改写为不使用继承的例子，并对代码的清晰性造成同样的负面影响。与支持多继承的语言相比，一门不支持多继承的语言，在表达能力上会有欠缺，并因此迫 使程序员时不时地编写复杂化了的代码。 

7.如今人们对框架的谈论比语言更多，比方说，针对Java的J2EE，语言被牢牢地束缚于该平台上，或者.NET，微软“提升了”框架而“伤害了”语言。对于此类做法，您的观点是？C++的进化是否需要一个框架？ 

Bjarne Stroustrup：关 于框架，人们谈论了很多，但是历史被“没有遂心如愿”的框架搞得乱七八糟。我看过成功的框架，但它们的应用范围通常有局限。我怀疑会不会存在“通用”框 架，尤其当这样的框架是“一个平台厂商为了同其他厂商的类似的框架竞争”而推出的产品时，我更加怀疑。作为一个用户，我倾向于尽可能地保持同厂商独立。

我希望看到“库”提供对框架更加清晰和更加通用的访问，我反对将语言紧密地系结于单一的框架。 

8.在“C/C++ Journal”对您的一次访问中，您说您对C++的目标之一是提高抽象层次，这一直是您的目标吗？ 

您真的能实现一个强有力的抽象层而不影响性能吗（比方说，Java在性能上就作了巨大的让步）？ 

您希望看到哪一种机制被集成于C++之中（垃圾回收机制…）？您希望改善何种机制？ 

Bjarne Stroustrup：尽可能更为清晰、更加直接地将程序员的意图表达于代码之中，一向是我的目标。因此，提高抽象层次，一直是我对C++的目标。 

是的，你可以显著地提高抽象层次，而不会牺牲效率。关键在于有一个富有弹性和扩展能力的静态（编译期）类型系统。标准库的STL 部分就是一个优秀的例子。例如，vector可以容纳任何类型（内建的或用户定义的）的元素，而没有什么额外负担。请注意，和Java相比，C++ vector容纳有用户定义类型的“值”，而不是用户定义类型的对象的“引用”。这既节省了内存（你无需为堆上的元素个体分配用于“引用”或“内存管理信 息”的内存），也降低了访问代价（没有“通过引用间接访问”的代价，也没有对“从vector内抽取出来”的元素进行类型检查的运行期代价）。无需在运行 期进行类型检查（转型（casting）），还带来了明显更为干净和简短的代码。另外一个例子是标准算法（比如sort），它可以用于任何相配的容器，并 可用一个“比较准则（comparison criteria）”加以参数化，并且仍然显著地比它们的C类似物（比如qsort()）来得快。 

我乐意看到C+ +标准委员会明白地认可垃圾回收机制是一个有效地C++实现技术，但我不希望使C++语义依赖于一个垃圾回收器。在某些应用领域（比如设备驱动和某些内核 代码），垃圾回收器并不合适。如果你希望在C++中使用垃圾回收机制，你可以使用现有的垃圾回收器之一。对于那些“自动垃圾回收是一种合理的技术”的应用 来说，它们工作得非常好。 

9.您将C++描述为一种多范型的语言，主要是面向对象和泛型。在下一个版本的C++中，我们可以看到什么样的范型？ 

Bjarne Stroustrup：我感觉“范型”一词被过度使用了，我宁愿使用不那么傲气的词语 — 编程风格（programming style）。而且，人们不应该忘记使用简单的“独立类”（也就是那些不属于某个层次结构中的一个组成部分的类）。对于许多现代C++技术来说，它们至关重要，富有弹性且高效，并且也是经典的“数据抽象”的例子。 

我不认为C++将很快支持一种新的“范型”，也可能在“什么叫范型”方面，我过于保守了。我希望下一个C++标准将支持分布式编程，但这首先要通过标准库达成。 

10.您有计划将AOP（Aspect Oriented Programming）集成进来吗？

Bjarne Stroustrup： 没有。我仍然没有搞清楚AOP是怎么符合我的指导原则的 — 在代码中独立地表达独立概念，并且当（且仅当）需要时，可以自由地将它们结合起来。我也不清楚它有多么通用，以及它的概念有多么普遍的意义。记住，只有当你通盘考虑了备选方案后，你才可以向一门被广泛使用的大型程序语言中加入新的特性。 

请注意，在我的主页上可以找到许多C++ FAQ和相应的答案。在那儿，你还可以找到许多文章，以及一些有用的C++链接。