首个 C++ 编译器诞生 30 周年了，来听听 C++ 之父畅谈 C++

C++ 之父 Bjarne Stroustrup 在 cfront 诞生 30 周年的访谈。

其实倒没有刻意的重要意义，但我觉得同时发布是个不错的主意。因为 AT&T（美国电话电报公司，也是贝尔实验室当时的母公司）和 Addison-Wesley（著名科技书籍出版公司）当时都问我选哪天合适，我就跟他们说 10 月 14 日合适。因为那天我要在 ACM（美国计算机学会，也是计算机最高奖图灵奖的颁发机构）大会上作一个演讲，我想在演讲中宣布这个事情。

我认为这本书是非常必要的。当时的C++社区规模还很小，但是发展却非常迅速，社区需要这本书。其实写书一开始都不是我自己的主意。Al Aho，我在贝尔实验室的邻居，是他指出社区的这种需求的。我那时完全低估了写《C++编程语言》这本书所需要的工作量。写书写得清楚明白是很困难的。我 真的是做了很多努力，以便清楚地向大家介绍C++。C++本身也做了改进，从逻辑性和功能性上做了增强，从而使我的阐述能够变得容易一些。另外，给这本书 写例程也是一个很需要技术和效率的工作。

其实我不记得了。实际上，我对在八十年代发生的大多数事情都没什么印象了。因为我那个时候实在是太忙了。从1979年到1991年间，C++程序 员的数量每7.5个月就翻一倍。这种增长的速度造成了很大的工作量。截至到今天，C++用户的数量大约有440万，详情看《全球有多少 C/C++ 程序员？》。这对我来说可是个大日子。但是我现在唯一有印象的事情就是我拿到第一版的《A C++ Tutorial》的那一刻。

“我确实做了大量的工作，以便让大家了解C++”

感谢 Paul McJones 提供照片

很显然，当时我根本没料到C++会发展到如此数量，以及C++爆炸性的增长。我当时的注意力都放在了诸如对语言的改进，对类库的丰富，对编译器的改进，以及对语言进行推广教学上。

另一方面，我们今天熟知的大部分C++的特性都与那个最初的年代渊源颇深。类，函数声明（函数原型），构造函数，以及析构函数都是一开始就引入的 语言特征。几年以后，我又引入了内联函数和对操作符的重载。当时对初始化和赋值的特性已经区分开了。通用的操作符重载则是几年以后引入的（大约在1983 年左右），虚函数机制也差不多是那个时候引入的。人们通常不太会记得，一开始C++是没有参数化的类型的（也就是template——译者注）。在 CFront的早期版本里，我是用一个向量宏，然后把元素的类型作为一个宏参数传入，以此来实现泛型的逻辑，这些实现都包含 在<generic.h>头文件里。随后几年，我觉得用宏的方式来实现泛型已经足够了。现在看来我当时的这种观点真是非常错误的，不过我认为 （非向量之外的）其他数据类型还是很需要参数化类型的，我的这个判断还是正确的。所以后来模板诞生了（1988年）。

C++的基本设计思想，是要给这门语言提供一种可扩展机制，以便用户可以定义强大、优雅而且高效的抽象模型。这种设计思想与面向某种特定应用的语 言截然不同。直至今日，C++仍然支持C语言的机器模型，使得用户能够在移动设备上高效合理地编程。我们也依然坚持采用循序渐进的方式对C++进行改进， 确保C++对抽象的有效支持。

对此我的感觉是既骄傲又有点惶恐。能够创造出一个经得住考验的产品当然是很棒的，但是同样附带的责任也非常巨大——尤其是在语言进化这个方面。如 果我们能把优秀的，有用的特性加入到语言中，那么我们就为世界做了大好事，可是如果我们搞砸了，那带来的危害同样也会很大。目前，我认为C++的进化是在 有条不紊地进行。并不是说之前所有引入的特性都是成功的，但是我们引入的有用的特性要远远多于那些彻底失败的特性。每一年，C++都在朝着更好的方向发 展。如今的C++已经比1985年推出的那个1.0版本优秀了无数倍。今天，我们能够写出比以前更优雅，更高效的代码（即使是你把硬件性能的差异考虑进 来，也是如此）。

“C++的演进采用了小心谨慎，循序渐进的态度，而且与现实问题息息相关。”“C++在不停地成长。它不是一个”象牙塔项目”

提到成功的原因？原因肯定是复杂的。想要获得成功，一个语言需要满足用户的任何需求，而且还要保证在各方面都不能出错。所以在一两个点上做到世界 第一，那是完全不够的。首先，C++在那些对性能和硬件资源相关的编程方面（这个领域称为”系统编程“）独占鳌头，尤其是对那些复杂度需可控的系统更是没 有对手；其次，C++的演进采用了小心谨慎，循序渐进的态度，而且与现实问题息息相关。C++在不停地成长。它不是一个”象牙塔项目“，（目标宏大，结构 复杂但脱离现实——译者注）。最后，我认为非常重要的一点是，C++不会去迎合那些花里胡哨的东西：我采用了相对谦虚谨慎的态度来发展这门语言，并且一直 将这种风格保持了下来。

“我有好几次想脱离C++的开发，但是最后总是又被拖回来继续干。”“如果要从头发明一种语言，太容易犯错了。一个成功的大系统，往往都是由一个个小系统逐步进化而来的。”

我有好几次想脱离C++的开发，但是最后总是又被拖回来继续干。我感觉从事C++方面的工作对我来说是贡献世界最好的机会了吧。毕竟，C++是我 从事研究和开发的主要工具。那些经验和教训——来自于我本人或C++社区的无数参与者——会及时反馈到语言本身，以及相关类库上，这样就能让数以百万计的 人得益。

我当然有想过要设计一门更好的新语言，但对于一门语言来说，要实现从思想到工具的转变，这个过程太漫长了。况且C++在自己的地盘上几乎没有对 手，所以我还是把我的兴趣放在如何把C++打造成一套优秀工具上吧。另外还有一点，大部分新发明的语言都失败了。如果要从头发明一种语言，太容易犯错了。 一个成功的大系统，往往都是由一个个小系统逐步进化而来的。

鉴于C++漫长的进化历程以及复杂度，要把一个新特性整合到其中是非常困难的，但是一旦某种特性被采纳了，那么这个特性将会被数以百万计的用户使用。这样规模形成的影响力，比创造一种新语言然后给几百个早期用户使用要大得多了。

机器模型没变，对（编程语言）抽象能力的追求也没有变，而且这两者像以往一样相互关联。这也是我一直强调使用静态（编译时）类型系统的原因。

对异常机制和模板这两种特性的支持大大改进了这门语言，使得人们可以书写优雅而高效的代码。我在1986年为《IEEE软件》期刊撰写的论文中， 第一次提出了这两种语言特性的概念。异常机制，连同构造函数和析构函数，在资源管理方面提供了安全保障（RAII）。模板则为 Alex Stepanov 实现STL，以及日后泛型编程的繁荣奠定了基础。在这一年里，我们实现了对概念的语言级支持，从而完成了模板机制。

“1980年后期，人们对类的层次结构的用法非常狂热。”

“我还做过报告，报告的题目就叫“C++不仅是一门面向对象编程语言”。”

“稍后，人们又对使用模板非常狂热。”

1980年后期，人们对类的层次结构的用法非常狂热。那时我倒是不愿意跟风，我更愿意把不同的编程风格混合，从而形成一个相互关联的整体。我写的 书的第一版（故意）没有使用“面向对象编程”这个词。我还做过报告，报告的题目就叫“C++不仅是一门面向对象编程语言”。稍后，人们又对使用模板进行泛 型编程，以及模板元编程非常狂热，认为语言设计的基本元素越少越好。而我则还是在寻找各种方法，来阐释我的理解，我认为优雅的编程语言是基于语言特性和类 库机制的综合体。

最近，我认为还有一件事情会在未来的几年内变得非常重要，那就是要努力制定出一套工具和类库编码指导书。这个东西会帮助C++社区更有效地应用新的语言机 制。在这方面的一个新例子，就是我们现在有工具可以用来消除“野指针”，从而为开创一个完全类型安全，资源安全的新局面提供了可能。尤其是，我们在不使用 “垃圾回收机制“（因为我们根本就不产生垃圾）的前提下避免了资源泄露，这样一来我们就不用为了增强安全性而忍受性能损失之苦了。当然， 我们不会限制C++的用途 。

我希望这能够帮助C++解决长期以来一直被人们诟病的问题：糟糕的教学和糟糕的理解，即使对于C++从业者来说也是如此。业界存在一种趋势，总是把C++ 描述成各种怪异的东西。比如，C++经常在教学中被称为是”一种增加了语言特性的 C 语言“，或者被称为”和 Java 差不多，但是不如 Java 安全，还缺少了一些高级语言特性。”这些说法对现实中C++的应用都造成了非常负面的印象。对此，我希望我最新版的 《C++之旅》 能有所帮助。我在这本书对C++语言本身，以及所有标准库都进行了高层次的描述，但是书的篇幅比经典的 K&R 的C语言教程还要少。本书面向有经验的程序员，对于完全的新手来说则不合适。

委员会将于下周在夏威夷的Kona开会，会后C++17将会颁布。我自己很难预测C++17会是什么样子。但是我（还是）很乐观的。C++11相对于C++98来说，是一个重大的进步，我也希望C++17相对与C++11来说，也能达成同样重大的进步吧。