Bjarne Stroustrup：标准化进程其实是一项极具价值的重大活动，但是人们对它认识太不足了，而且整个进程也是荆棘满途。实际上，通过标准化活动，C++语言显得越发成熟和完善了，还因此而获得了有着惊人表达能力的标准库。编译器的厂商老想束缚住他们的用户，而正式的标准化活动，则是用户们为数不多的自卫手段之一。 很难说哪一件事是最特别的。在委员会中，大多数的工作都是发现、提炼和建立信任的这样一个过程，这都需要花费大量的时间。不过最重要的事莫过于以下两件事，其一是1990年基于《The C++ Programming Language》第2版的参考手册（有模板和异常处理机制的那一版）进行C++标准化的那第一次的投票，其二则是1998年批准ISO标准的最终表决。毋庸置疑，在这两件大事当中，将STL接纳为标准库一部分的投票是一件最令人欢欣鼓舞的快事。 可以说，没有任何负面或者遗憾的事情能与这些具有进步意义的投票相提并论。说到"遗憾"，要么是一些十分微小的技术细节，要么就是那些（暂时）分化了委员会而使进展缓慢的讨论。例如，我本来是反对C风格的强制类型转换，也不想引入仅允许整型的静态常量成员在类中初始化的机制。不过，这都是些无关痛痒的小节。 我正期待着另外一次关键的表决。明年（2002年）的某个时候，委员会将决定ISO C++的未来方向，这可是头等大事啊！
Bjarne Stroustrup：对此，我已经没有多少可补充的了。在模板成为C++的一部分之前，Alex和我曾经花了一些时间去讨论语言特性。从我的角度来看，当时的Ada经验给他施加了过大的影响，而Alex有着自己的优势--泛型编程的宝贵实践经验，这恰恰是我的不足。他强化了我对不牺牲效率和内限制表达能力或牺牲效率的实现方法。尤其是过去我对能否把模板参数限制在继承层次持怀疑态度，如今我态度依然。联的偏好。我们都讨厌宏而喜欢类型安全。他本来想要更强的模板参数的静态类型检验，我也是这么想的，不过还没有找到可以不 后来Alex创造性地使用了我所设计的模板特性，这就导致了STL的诞生，使得目前人们开始重视泛型及生成编程。跟Alex争论很有意思！关于我对他风格的印象，参看http://www.stlport.org/resources/StepanovUSA.html【记者注：这是一篇STL之父Alexander Stepanov的访谈录，内容相当激进，心脏不好的人请做好一切必要准备^_^。Alex在GP上有极深的造诣，这篇访谈颠覆性不小，甚至可以看到他对OO的批判！也许彻底抛弃OO很难，但Alex的话确实富有启发性，值得一看】。 我曾经试验过多种在不使用语言扩展的情况下约束模板参数的方式。个人早期的想法在《The Design and Evolution of C++》（《C++语言的设计与演化》的中文版和影印版均已由机械工业出版社引进出版）一书中已有详述，其后期的变体如今成为了普遍使用的约束和概念检查的一部分。这些系统在表现力和弹性上比在其他语言中的常见内建设施要强很多。如果要举例的话，可以参阅我的C++ Style and Technique FAQ（http://www.research.att.com/~bs/bs_faq2.html#constraints）。
Bjarne Stroustrup：我不想替这次转变再多说些什么了。然而，我想强调的是原来我所设计的流库简单且高效，我在两个月内就完成了设计和建构。 那次关键的决策把格式与缓冲分离开来，并使用了类型安全的表达式语法（依赖于<<和>>运算符）。与AT&T贝尔实验室的同事Doug McIlroy进行了一番探讨之后，我最终做出了这些决策。实验表明，诸如<、>、逗号和=都不太合适，后来我选择了使�<<和>>。类型安全使得在编译时就可以决定一些原本在C风格库中需要在运行时才决定的事情，因而其性能非同一般。在我刚开始使用流以后的不久，Dave Presotto就把我的实现的缓冲部分替换成一个更出色的部分，我一直都没有注意到这一点，直到他后来告诉我。 目前的IO流肯定小不了。不过我坚信，在许多通常没有使用IO流全部通用性的情况下，借助于强力的优化，我们可以重获原来的效率。注意，IO流之所以如此复杂，大部分的原因是为了满足那些我原来所设计的经典流没能考虑到的需求。例如，带本地化的标准IO流就可以处理经典流力不能及的汉字和汉字串。
Bjarne Stroustrup：我喜欢"面向金钱"这个词 :-) 还有Andrew Koenig的成语"面向大话"我也喜欢。 不过，C++可不面向这两个东东。 对这点我还想指出，我认为纯粹性并不是优点。C++的强项恰恰在于它支持多种有效的编程风格（多种的思维模型，如果你一定要这么说）以及他们之间的相互组合。最优雅、最有效也最容易维护的解决方案常常涉及不止一种的风格（编程模型）。如果一定要用吸引人的字眼，可以这么说，C++是一种多思维模型的语言。在软件开发的庞大领域之中，需求千变万化，需要至少一种支持多种编程风格的通用语言，而且很可能需要一种以上。再说，世界之大，总能容得下好几种编程语言吧？那种认为一种语言对所有应用和每个程序员都是最好的看法，本质上就是荒谬的。【注：paradigm的中文翻译似乎没有约定。有人偏好"典范"或者"范式"，记者则喜欢侯捷先生使用的"思维模式"或者"思维模型"。总之，paradigm的大概意思是an example or pattern，大家理解就行。】 Java和C#的主要力量源自于其所有者的支持。这意味着低价（为取得市场份额免费发放实现和库），集约和不择手段的营销（欺骗宣传），以及由于缺乏替代厂商而产生的表面上的标准。当然，就Java的情形而言，当其他厂商和修改版本出现后，版本、兼容性和移植问题也会像其他语言一样，重新冒出来。 不被语言所有者操纵的开放进程所产生的正式标准是最好的。如果用户不想看到这种语言为了其发起者或所谓"一般用户"的利益，而不顾经济上无足轻重的"少数派"反对而来回折腾，像ISO这样正式的标准进程，则是他们唯一的希望了。 C++本可以更简单或更易用些（更纯粹，如果你认为这是必要的），不过这样就无法支持那些有着"不同寻常"的需求的用户了。我个人很关注他们，他们要构建可靠性、运行效率以及可维护性远高于行业平均水准的系统。我的猜测是，在10年内大多数的程序员都将面临"不同寻常"的技术要求，他们可以从C++的多思维模型结构中受益，而Java和C#之类"简化"语言则力有不逮了。 我认为模板和泛型编程是现代C++的核心，是无损效率、类型安全代码的关键。然而它们并不适合经典的面向对象编程思维模型。
Bjarne Stroustrup：Ian Joyner对C++的观点，我不敢苟同。撇开这点，垃圾收集可能算是有价值的技术，不过并不是万能丹，它也会带来问题。对C++而言，自动垃圾收集是一个有效的实施技术，有许多为C++设计的不错的垃圾收集器（商业支持和免费的都有），而且也被广泛地使用（参看我的C++页面上的链接）。然而C++中垃圾收集机制应该是可选的，这样在不适合垃圾收集的地方，如严格的实时应用程序，可以免受其累。关于垃圾收集，我的《The C++ Programming Language》（《C++程序设计语言》）一书和我的主页上都用评注，可以参看。 我期望在下一个C++标准中能体现出我的意见，并做出明确的声明。就此而论，C++可以优雅地处理一般的资源，而不仅仅局限于内存。尤其是"resource acquisition is initialization（资源获得就是初始化）"技术（参看D&E、TC++PL和我的技术FAQ）支持对任意资源进行简单并且符合异常安全（exception-safe）要求的管理。没有析构函数的Java不可能支持这一技术。
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++网页有链接）。
Bjarne Stroustrup：我认为，在C++中面向对象和泛型编程相得益彰，我所写的许多最优美的代码段都是两者的结合。也就是说，那些认为OOP和GP水火不容的观点是错误的。它们是应该组合使用的技巧，语言应该支持这样的组合──C++正是如此。 我觉得C++相当好地支持了泛型编程，所以只需要细微的增加。模板化的typedef是个显而易见的例子。我们要谨慎地扩展语言，仅当扩展对要表述的内容提供重大的便利时，我们才这样做。比如我不支持对模板参数约束检查提供直接语言支持的想法。通过约束／概念检查模板，我们已经可以比用为C++和相似的语言提议的各种各样的语言扩展做得更多。 谈起"思维模型"和"新的思维模型"让我很为难，只有很少的想法佩得上这样美妙的字眼。我也担心对新观念过于直接的支持，可能会限制和跟不上我们的观念和技术的进一步演化。理想的情况是，语言设施应有效地支持非常通用的观念，这样大家可以使用这些设施用各种风格来编写代码。至于C++能优雅地支持哪些模式概念，能和不能通过与已有风格的组合，还有待观察。我认为，只需要很少新的特定语言概念来支持模式。
Bjarne Stroustrup：对。如果事情进展能如我所愿，C++标准的下一次修订会通过提供扩展的类型信息和并发支持库来支持分布计算。我觉得这不需要特别的语言扩展。不过在存在并发的情况下现有语言设施实施需要做出额外的保证。 我没有太多可说，因为围绕下一标准应该和不该包含哪些的讨论才刚刚开始。我的看法是C++需要一个无缝地支持线程（在同一地址空间内）、进程（在不同地址空间）及远端进程（可能有重大的通讯延时而且网络可能暂时分离）的标准库。支持这点会需要超越简单的Unix或Windows线程的设施。但是我并不认为这需要设计新的语言元件。
Bjarne Stroustrup：我并不清楚是否有人觉得我真的与众不同。我猜想自己可能比多数人天真和显得理想主义那么一点点。此外，比起大多数人，我花在解决现实问题的时间会多一点吧──我要挣钱以免债台高筑。我可不能如此，因为家里并不富有，我一直被告诫要勤奋工作。另一方面，我喜欢学习自己感兴趣的许多东西（包括哲学和历史），而不仅仅是那些直接有助于我取得学位和提高成绩的东西。
Bjarne Stroustrup：作为一名丹麦人，我当然知道安徒生童话。恰好我也很喜欢这些故事。在《夜莺》里描绘的中国纯属虚构，与当时的中国可能有也可能没有任何联系。安徒生创造的那个"中国"，是用来泛指许多个国家及其统治者的。 中国是个巨大的概念Bjarne Stroustrup，很难能对之有一个总体的印象。我所遇到的中国人大都是程序员或者工程师，因此我对中国人的看法可能会过于狭隘。纵使是类似于我的本国丹麦这样的小国和文化体也是十分复杂的，不是单个人能够完全理解的──丹麦只有500万人口。我对历史很感兴趣，因此也看了数本有关中国历史和文化题材的书籍。不过这可能意味着我头脑里的中国会比较古老，与现在的中国并不能相提并论。我在台湾进行过一个星期的讲学，那里挺不错的，不过目前我尚没有机会访问大陆。 关于中国历史和文化的书我看过不少。中国历史悠久、幅员辽阔，因此书的内容就集中于早期的事件、人和传统，几乎没有描绘近10年或者20年的中国。尽管从新闻和中国朋友那里得知中国已经发生了巨大的变化，但是我对今日的中国还是相当无知（但是可能比大多数人对远方国度的那种无知要强一些），比如我对当今中国的文学和音乐一无所知。因而一旦想起中国，我就可能想起很多严重过时的东西──尽管自己极力去避免此类的错误。这里顺便说一句，我对主要从书本上获知的世界其他地区也都有类似的问题。 我对大型人群和有组织的群体事件不太热心，因此我会远离2008年奥运会，就象我远离那些原本可以参与的各届奥运会一样。我希望能找个除此之外的机会访问中国。
|
||||||||||||||||||||||||||||||||||||||
感谢C++
View让我们转载它的这篇专访（2000-2002 C-View.ORG All Rights Reserved），未得C++
View同意，任何人请勿将此文再做转载。采访：虫虫，翻译：ALNG Bjarne Stroustrup博士，C++语言的设计者和最初实现者，现任AT＆T实验室的大型程序设计研究部的主管。著有