专访C++之父Bjarne Stroustrup

采访：虫 虫  翻译：ALNG

感谢C-View.org准许转载

编者按：在C++ View第1期中我们介绍了这位C++之父，相信大家都很熟悉了。这次，小编对这位大人物进行了专访，非常感谢Stroustrup博士的精彩回答和耐心的解释。感谢cber添补的问题，和对小编中国式英语的纠正。同时还要感谢ALNG精彩的中文翻译，这能方便大家更好地理解Stroustrup博士的深邃思想。关于翻译的一些细节问题，小编与ALNG争吵了整整一天，大体上达成了一致。有些需要说明的地方，都在文中加入了相应的注释。不过小编还得声明，Stroustrup博士回答的内容均以英文为准。

C++ View：C++的ANSI/ISO标准化标志着C++的成熟。能告诉我们在标准化过程中，您感到最难忘、最快乐以及最遗憾的事分别是什么吗？

Bjarne Stroustrup：标准化是一个极其有价值的重要活动，它在很大程度上被低估，困难重重。通过标准化，C++变得更好了，还获得了有着惊人表达力的标准库。编译器提供商总是想锁定用户，正式的标准化则是用户拥有的为数不多的防御手段之一。

很难挑出特定的事。委员会的大多数工作形式上都是发现、提练、建立信任的过程，要花时间。不过最重要的事一定是1990年对以The C++ Programming Language第二版（其中引入了模板和异常机制）作为参考手册来标准化C++的初次投票或1998年批准ISO标准的最终表决，两者之一。

没有任何负面或遗憾的事可以与这些积极的投票相提并论。所谓“遗憾”的事，要么是细微的技术细节，要么是（暂时）分化了委员会而使进一步的进展更加困难的讨论。我本来是反对C风格的cast，也不想引入仅允许整型的静态常量成员在类中初始化的机制。不过这些只是无关大局的细节。【注：cast翻译成什么好呢？其本意是铸造、打型，诸位以为，“映射”、“转换”、“型铸”哪一个翻译更贴切呢？或者有其他更好的翻译？】

我期待着另外一次重要表决。明年某个时间委员会将决定ISO C++的未来方向，这可是头等大事啊！

C++ View：C++的标准化为何会困难重重？另外可以再谈谈委员会里的工作进程吗？

Bjarne Stroustrup：标准化是个缓慢的进程，常常聚焦在琐细的技术细节上。你要让几十个来自不同国家、受过不同技术教育的人达成一致，并需要代表着各种组织（或仅仅本人）的委员富有成果地合作。C++委员会不是一个满足于60%对40%的差距“获胜”的组织。我们认为这样的表决结果就是失败。我们的目标是一致同意，意思是“基本人人赞同”。我们为达成一致不懈努力。很艰难，差不多每个人──起码是有时候──都希望有一个快捷一点的方式。当然，我们的成果是一个公认能很好地满足一个大得难以置信的群体的需求的语言，而不是对某一用途或某个人来说的完美语言。最终我们达成了标准的一致通过（ANSI中43-0， ISO中22-0）。有人告诉我，对编程语言标准而言，这一赞成度前所未有。

首先委员会要弄清真正的问题和可行的技术解决方案。我称之为“发现”。接着我们把解决方案提炼成标准文本中精确描述的东西。参加标准过程的个人总是必须学会相互协作以及相信他人的善意和专业才能。我称之为“建立信任” ──这非常可能是标准进程中最重要的一部分，没有互信我们将一事无成。

C++ View：Alexander Stepanov说有一次他曾和你争论。因为他认为C++的模板函数应该象Ada通用类一样显式实例化，而你坚持认为函数应使用重载机制隐式实例化。由于你的坚持，这一技术后来在STL中发挥了重要作用。能和我们讲讲这个故事吗？

Bjarne Stroustrup：我没有多少可补充的。在模板成为C++的一部分之前，Alex和我花时间讨论过一些语言特性。在我看来，那时Ada上的经验给了他过分的影响，而他有着我很大程度上缺乏的宝贵的泛型编程的实践经验。他加强了我对不牺牲效率和内联的偏爱。我们都讨厌宏而喜欢类型安全。他本来想要更强的模板参数的静态类型检验。我也这么想，不过找不到可以不限制表达能力或牺牲效率的实现方法。尤其是，我过去是，现在还是，对把模板参数限制在继承层次的努力持怀疑态度。

后来Alex创造性地使用了我设计的模板特性，导致STL的产生，使目前人们开始重视泛型（generic）及生成（generative）编程。和Alex争论很有意思！关于我对他风格的印象，参看http://www.stlport.org/resources/StepanovUSA.html【注：这是一篇STL之父Alexander Stepanov的访谈录，内容相当激进，心脏不好的人请做好一切必要准备^_^。Alex在GP上有极深的造诣，这篇访谈颠覆性不小，甚至可以看到他对OO的批判！也许彻底抛弃OO很难，但Alex的话极富启发性，值得一看】。

我试验过在不使用语言扩展的情况下约束模板参数的多种方式。我早期的想法在The Design and Evolution of C++一书中有叙述，其后期的变体成了现在普遍使用的约束和概念检查的一部分。这些系统在表现力和弹性上比常见于其他语言的内建设施要强太多。如果要举例的话，可以参看我的C++ Style and Technique FAQ（http://www.research.att.com/~bs/bs_faq2.html#constraints）。

C++ View：Jerry Schwarz在Standard C++ IOStream and Locales一书中的前言中回顾了IOStream的历史。我想在从经典流到标准IOStream的转变过程中一定有很多趣事，您能不能给我们讲一些呢？【注：此书由德国Angelika Langer和Klaus Kreft夫妇编著，是迄今为止该领域最权威和最完整的著作，中文版《标准C++输入输出流与本地化》由人民邮电出版社出版。】

Bjarne Stroustrup：我不想再给Jerry对从我设计的流到目前的IO流转变的叙述添砖加瓦。然而，我想强调原来的流库简单而高效，我花了两个月的时间来设计和建构。

关键的决定在于格式与缓冲的分离，并使用类型安全的表达式语法（依赖于<<和>>运算符）。与AT&T 贝尔实验室的同事Doug McIlroy探讨后，我做出了以上决定。实验表明，诸如<、>、逗号和=都不适合，后来我选择了<<和>>。类型安全允许一些原本在C风格库中需要在运行时决定的事，可在编译时决定，因而提供了非凡的性能。我刚开始使用流后不久，Dave Presotto把我的实作的缓冲部分透明地替换成更好的，不过后来直到他告诉我，我才注意到这点。【注：请注意“透明（transparently）”这个词，也许这个翻译不是特别好，但是说明一点，Stroustrup设计的这个流库相当出色，结构相当漂亮，甚至于库的一部分被换掉了，其功能丝毫不受影响，居然连其作者也没有察觉！】

目前的IO流肯定小不了，不过我相信，在许多通常没有使用IO流全部通用性的情形下，借助于强力的优化，我们可以重获原来的效率。注意，IO流那样的复杂度是为了应付我原来的经典流没有考虑的需求。例如，带本地化的标准IO流就可以处理经典流力不能及的汉字和汉字串。

C++ View：有人说Java是纯粹面向对象的，而C#更胜一筹。而还有很多人说它们纯粹是面向金钱的。以您之见呢？

Bjarne Stroustrup：我喜欢“面向金钱”这个词 :-) 还有Andrew Koenig的说法“面向大话”我也喜欢。 C++可不面向这两个东东。

对这点我还想指出，我认为纯粹性并非什么优点。C++显著地强项恰恰在于其支持多种有效的编程风格（多种思维模型吧，如果你一定要这么说）及其组合。最优雅最有效也最容易维护的解决方案常常涉及到一种以上的风格（编程模型）。如果一定要用吸引人的字眼，C++是一种多思维模型的语言。在软件开发的庞大领域，需求千变万化，起码需要一种支持多种编程的设计风格的通用语言，而且很可能需要一种以上呢。再说，世界之大，总容得下好几种编程语言吧？那种认为一种语言对所有应用和每个程序员都是最好的看法，根本就是荒谬的。【注：paradigm的中文翻译似乎没有约定。ALNG偏好“典范”或者“范式”，小编则喜欢侯捷先生使用的“思维模式”或者“思维模型”。总之，paradigm的大概意思是an example or pattern，大家理解就好。】

Java和C#的主要强项是从其所有者那里得到的支持。这意味着低价（为取得市场份额免费发放实作和库），强力到无耻的营销（欺骗宣传），以及由于缺乏替代提供商产生的标准表象。当然，就Java的情形而言，当其他供应商和修改版出现后，版本、兼容性和移植问题也会像其他语言一样重新冒出来。

不被语言所有者操纵的开放进程所产生的正式标准是无可替代的。如果用户不想看到这种语言因为其所有者或者所谓“一般用户”的利益，不顾经济上无足轻重的“少数派”的反对而改来改去，像ISO这样正式的标准进程，则是唯一的希望。

C++本可以简单点或容易使用点（更纯粹，如果你一定要这么说），不过这样就无法支持那些有着“不同寻常” 的需求的用户了。我个人很关注这么一些人，他们要构建可靠性、运行效率以及可维护性远高于行业平均水准的系统。我的猜测是在10年的跨度中大多数程序员都将面临“不同寻常”的技术要求，他们可以从C++的多思维模型结构受益，而Java和C#之类“简化”语言则爱莫能助。

我认为模板和泛型编程是现代C++的核心，是无损效率、类型安全代码的关键。然而它们并不适合经典的面向对象编程思维模型。

C++ View：Ian Joyner在C++??: A Critique of C++ and Programming and Language Trends of the 1990s一书中比较了C++和Java并批评了C++的许多机制。你赞成他的观点吗？尤其是多数新语言都有垃圾收集机制，C++中会加入吗？

Bjarne Stroustrup：Ian Joyner对C++的观点，我不敢苟同。撇开这点，垃圾收集可能算是有价值的技术，不过并不是万能丹，它也会带来问题。对C++而言，自动垃圾收集是一个有效的实作技术，有许多为C++设计的不错的垃圾收集器（商业支持和免费的都有），而且也被广泛地使用（参看我的C++页面上的链接）。然而C++中垃圾收集机制应该是可选的，这样在不适合垃圾收集的地方，如严格的实时应用程序，可以免受其累。关于垃圾收集，我的The C++ Programming Language一书和我的主页上都用评注，可以参看。

我期望下一个C++标准中能大体上对我上面和其他地方说的内容做出明确的声明。

就此而论，C++可以优雅地处理一般的资源，而不仅仅局限于内存。尤其是“resource acquisition is initialization（资源获得就是初始化）”技术（参看D&E、TC++PL3和我的技术FAQ）支持对任意资源进行简单并且符合异常安全（exception-safe）要求的管理。没有析构函数的Java不可能支持这一技术。

C++ View：STL是一个超凡脱俗的跨平台架构。有没有考虑在其他方面，比如GUI（图形用户接口），设计这样的标准架构？

Bjarne Stroustrup：很自然地，很多人会想如何在其他领域借鉴STL的成功。比如在数值运算和图论方面都有了许多有趣的工作。相关链接可以参看我的网页。

标准GUI价值极大，不过我怀疑其政治上的可行性。太多有钱的大公司在维持其专有GUI上有着重大的商业利益，而且要求用户放弃现在所使用的GUI库也殊非易事。【注：有朋友可能奇怪，一个GUI库怎么扯出“政治（politically）”来了？西方人口中的“政治”，在中文里并没有真正对应的词语。这里的意思是of concerning public affairs，跟中文里的“政治”无关。下一段就是对这个所谓“政治上的可行性”的详细解释。】

这里我所说的可行性是就商业和技术而言。现在有好几种广泛使用的GUI，即使标准委员会提供一个替代方案，它们也不会就此退出。其所有者和用户──常常有充分理由──会只是忽略新标准。更糟的情况：某些公司或群体会积极反对这样的标准，因为他们认为标准不如他们已有的库，或者因为差异太大而使得转换到新GUI不可行。必须理解，如果标准不能充分服务于其目标用户，用户会视而不见。许多ISO标准因为无人理会而变得无关紧要。C++标准可不想成为其中一员──把现有实作拉近到一起，标准就功德无量了──我们不希望将来ISO C++标准被人忽略。

注意STL成功的一个主要原因在于它是一个技术突破。它可不单是“又一个容器库”，因此它不需要和许多现有的容器库（其中几个品质卓著）直接竞争。我猜想C++要有一个标准GUI，我们需要技术突破，加上好运多多。

不过我还是怀疑委员会有由必需的专业技术和资源来构建一个可以成为真实世界中真正标准的GUI.

我对标准库的想法倾向于修补现有库的遗漏（如hash_map和正则表达式），以及通过更广泛的运行时间类型信息和并发库来支持分布运算（可选）。

有时大家忘了，库不是非得成为标准的一部分才有用。有成千上万有用的C++库。例如，参见C++库FAQ（我的C++网页有链接）。

C++ View：泛型编程是C++特殊的编程思维模型。你是怎样看GP（泛型编程）和OO（面向对象）的？将来C++会提供更强大的机制来支持GP吗？有没有考虑引入其他思维模型，比如面向模式？

Bjarne Stroustrup：我认为，在C++中面向对象和泛型编程相互补充得极好，我所写的许多最优美的代码都依赖于两者的结合。也就是说，认为OOP和GP水火不容的观点，是错误的。它们是应该组合使用的技巧，语言应该支持这样的组合──C++正是如此。

我觉得C++相当好地支持了泛型编程，所以只需要细微的增加。模板化的typedef是个显而易见的例子。我们要谨慎地扩展语言，仅当扩展对要表述的内容提供重大的便利时，我们才这样做。比如我不支持对模板参数约束检查提供直接语言支持的想法。通过约束／概念检查模板，我们已经可以比用为C++和相似的语言提议的各种各样的语言扩展做得更多。

谈起“思维模型”和“新的思维模型”让我很为难，只有很少的想法佩得上这样美妙的字眼。我也担心对新观念过于直接的支持，可能会限制和跟不上我们的观念和技术的进一步演化。理想的情况是，语言设施应有效地支持非常通用的观念，这样大家可以使用这些设施用各种风格来编写代码。至于C++能优雅地支持哪些模式概念，能和不能通过与已有风格的组合，还有待观察。我认为，只需要很少新的特定语言概念来支持模式。

C++ View：今后C++会支持分布开发吗？对RTTI和多线程的进一步支持呢？

Bjarne Stroustrup：对。如果事情进展能如我所愿，C++标准的下一次修订会通过提供扩展的类型信息和并发支持库来支持分布计算。我觉得这不需要特别的语言扩展。不过在存在并发的情况下现有语言设施实作需要做出额外的保证。

我没有太多可说，因为围绕下一标准应该和不该包含哪些的讨论才刚刚开始。我的看法是C++需要一个无缝地支持线程（在同一地址空间内）、进程（在不同地址空间）及远端进程（可能有重大的通讯延时而且网络可能暂时分离）的标准库。支持这点会需要超越简单的Unix或Windows线程的设施。但是我并不认为这需要设计新的语言元件。

C++ View：最近一个叫做YASLI的项目启动了。YASLI代表“又一个标准库实作”，其目的是成为新一代的C++标准库实作。您对此有何感想？【注：这个项目最初的想法来自于今年5月份Andrei Alexandrescu在news://comp.lang.c++.moderated上的讨论，详细信息可以在http://www.stlport.org上查找，也可参考http://www.stlport.com/cgi-bin/forum/dcboard.cgi?az=list&forum=DCForumID10&conf=DCConfID2。】

Bjarne Stroustrup：知之甚少，无从说起。

C++ View：据说大人物年轻时就会表现出与常人的差异，请问您在大学就读时表现过什么与众不同的地方？

Bjarne Stroustrup：我不清楚是否有人认为我显著得与众不同。我猜想，我可能比多数人天真和理想主义那么一点点。另外比之多数人，我花在解决现实问题的时间会多一点吧──我要挣钱以免陷入债务。我可不能债台高筑，因为我家不算富有，我一直被要求努力工作。另一方面，我倾向于学习我感兴趣的多种东西（包括哲学和历史），而不仅只是那些直接有助于我取得学位和提高成绩的东西。

C++ View：喜欢安徒生童话吗？在《夜莺》里他写到了中国。您对中国、中华文化和中国人的印象如何？以前去过中国吗？2008年来中国看奥运会可能是个不错的主意。

Bjarne Stroustrup：作为丹麦人，我自然知道安徒生童话。我刚好也很喜欢它们。《夜莺》中描绘的中国纯是虚构，与当时的中国可能有也可能没有任何关系。安徒生创造了那个“中国”来泛指多个国家及其统治者。

很难对象中国这么巨大的概念有一个印象。我遇到的中国人大都是程序员或工程师，因此我对中国人民的视野可能过于狭窄，有误导之嫌。哪怕是象我的本国丹麦这样的小国和文化体，其复杂程度也不是某个人可以完全理解的──只有500万丹麦人。我对历史很感兴趣，因此也看了几本中国历史和文化题材的书。不过这可能意味着我头脑里的中国古多于今。我在台湾讲过一个星期的学，喜欢呆在那里，不过还没有机会访问大陆。

关于中国历史和文化的书我看过不少。因为中国历史悠久、幅员辽阔，主要的焦点集中于早期的事件、人和传统，几乎没有描绘近10或20年的中国。从新闻和中国朋友那里获知发生了巨大的变化，我对今日中国的无知是巨大的（尽管可能不象多数人对远方国度那么无知）。比如我对当今中国的文学和音乐一无所知。因而，想到中国时我想起的很多东西可能都严重过时──尽管我极其小心地想避免此类错误。顺便说一下，我对主要从书本上获知的世界其他地区也有类似的问题。【注：Stroustrup博士对中国历史有相当的了解，在谈论姓“王”的中国人时，我提到世界第二大软件公司CA的总裁王嘉廉（Charles Wang），他则提及王安石。Stroustrup博士说“对当今中国的文化和音乐一无所知”，小编就暂时推荐了两首流行音乐。由于Stroustrup博士喜欢安徒生童话，小编就首先推荐了熊天平的《火柴天堂》，以《卖火柴的小女孩》为背景。另外一首《长城》，来自取得华语流行音乐最高成就的Beyond乐队（不过随着家驹的离去，这已是永远的回忆了）。新近的歌嘛，孙燕姿的《风筝》蛮好听的，下次再说吧，呵呵。】

我对大型人群和有组织的群体事件不太热心，因此我会远离2008年奥运会，就象我远离本可以参加的其它各届奥运会一样。希望能找其他某个时间访问中国。