技术奇异点

C++ 为什么会被设计成现在这个样子，我一直认为和 Bjarne Stroustrup 的个人背景有很大关系。按照 Stroustrup 自己在 《The Design and Evolution of C++》里的描述，设计 C++ 的动机来自于他完成博士论文的时候编写一个模拟器缺乏合适的工具。从这段描述里，我冒昧地认为 Stroustrup 暴露了他早期的局限性，他意识到必须有更好的工具来管理系统的复杂性，但是眼光仅仅局限在源代码的层次。他的模拟器是一个单独的 monolith，在寻求更好设计时，Stroustrup 仅仅追求如何更好的管理这个 monolith 的内部结构，未曾考虑任何更高一级的方法——比如把 monolith 分割成相互协作的更小的模块——来提高系统的可维护性。

C++ 与进程开销

C++ 在 UNIX 上受到的欢迎程度最低，正是因为 UNIX  提供了更多的组织系统的方法，这些方法能够，而且经常是更好的代替源代码级别的方式。UNIX 不仅提供了进程和 IPC，让这些方式成为可能，而且还从一开始就不断寻求降低这些方法的开销，让它们相对于源码级的管理方式——也就是语言——更加有竞争力。所以，在 UNIX 上 C++ 没有获得它在其它一些操作系统中获得的那种主导地位。

在《The Art of UNIX Programming》的3.1.3节说的很清楚，“如果操作系统让创建进程的操作过于昂贵，或者让进程控制的操作过于困难或者过于死板，⋯⋯就会鼓励 (在一个较大的 monolithic 模块内部使用) 像 C++ 一类的源代码级别的内部分层结构，而不是 C 这样的 (在相互协作的小模块中) 相对平坦的内部结构。

我常说一句不太准确的玩笑话—— “C++ 就是微软捧起来的” 。其实也不是全无道理。作为在 PC 发展的黄金时代最广泛应用的操作系统，Windows 没有提供太多的系统级机制来管理应用软件的复杂度，开发者只能着眼于源代码级别的内部结构，寻求 C++ 之类的语言帮助。

C++ 的兴起和 PC 上 anti-UNIX 风格暂时的主导地位有很大关系。Stroustrup 的发明是对 UNIX 上管理系统复杂度的方式的一种不高明的重复。这种重复为那些由于历史原因或者因为经济原因 (比如过弱的硬件支持和操作系统支持) 没有普及 UNIX 文化的领域提供了一种似是而非的，拥有短期效益的替代品，因而受到了欢迎。

C++ 与内部复杂度

UNIX 文化鼓励通过进程和进程协作来降低单独模块的内部复杂度，而不赞成用 C++ 的方式来 “管理” 内部复杂度。事实上，UNIX 文化认为 C++ 的方式在鼓励过度的内部设计而不是有效的对其进行整体管理。

另一方面，C++ 不光忽略了在单个 monolith 的层次之上的管理方式，还低估了现有手段在单个 monolith 中应对复杂度的能力。做出这种错误判断的不只 Stroustrup 一人，在 90 年代操作系统领域兴盛一时的对 micro-kernel 的研究中，研究者和很多业界开发者都认为操作系统内核的复杂度已经到了必需舍弃 monolithic 式的内核设计，由 micro-kernel 加 user-space 进程实现的服务来替代。Linux kernel 的出现及时证明，用 C 这样的技术也足以很好的管理单个 monolithic kernel 的复杂度。Linux kernel 不光和很多 monolithic 内核同样稳定，还在性能和设计复杂度上拥有天然的优势。(比如，对于 Minix 的单线程文件系统的抱怨，其设计者反驳说该 feature 很好实现——但是始终没有真正实现，而对于 monolithic 内核来说，多线程文件系统几乎是自然而然的设计。)

今天，如果你把系统中某个组件的复杂度设计的比 Linux kernel 还高，那是一种罪过而不能被认为是必需使用 C++ 的理由。

结论

C++ 的兴起，在我看来很大程度上是不是一段普通的历史，而是反映了整个业界的一个错误。正如《The Art of UNIX Programming》所说，上世纪80年代，由于各个 UNIX 厂商的愚蠢，UNIX 文化曾经一度奄奄一息。而 UNIX 社区的开发者们又一再忽略兴起的 PC 市场 (而忘记了 UNIX 自己就是在 mainframe 的厂商忽视了 mini-computer 的情形下发展起来的)。在整个世界缺乏 UNIX 文化的情形下，出现了 C++ 这样畸形的尝试。

我承认世界并非完美。有些错误已经成为文化的一部分被保留下来。但是 UNIX 文化因为它强大的生命力终于逐渐回归。这显示出 C++ 不属于那类可以出于历史和文化原因而被永远保留的错误。这个错误至少应该不被扩大，并且可以被逐渐纠正。

垃圾回收不是自动变速

最近几天遇到的好几个和内存回收有关的 C++ 程序的 bug 。有对同一个指针两次调用 delete ；还有在 delete 了一个对象之后又通过其它地方保存的指针调用了这个对象的方法。当然从开始学 C++ 就明白要绝对避免这些问题，但是如果两段没有配合好的代码在 call stack 里相隔几十个函数调用的时候，避免并不像一开始想想的那么容易。

造成内存回收问题的根源在于程序的复杂度增长带来了程序运行时的不确定性，程序员无法准确判断一个对象真正不再被使用的时机。最著名的不确定性的来源当属多线程。但是单线程的程序也会有及高的不确定性。今天在 Mac OS X 或者 Windows 之类的操作系统上编写一个拥有 UI 的应用程序，可以很少或者根本不使用多线程——程序的大多数动作都可以在消息处理线程内完成。这样的单线程机制可以让 UI Framework 的设计和使用简单一些，能在大多数情况下避免线程同步操作的使用。但是当程序越来越复杂时，即使不引入多线程，单一的消息处理线程本身具有的不确定度绝对不比多线程低。

一些比较费时的函数有时会在整个函数的运行过程中的某些步骤把控制权暂时交还给系统的消息处理框架。如果在某个消息处理函数中调用了这样的函数，就会导致在这个消息处理函数会被不能确定的其它消息处理函数打断。有时候一个顺序过程的几个步骤会在多个消息处理函数调用中分别完成，触发这些消息处理函数的消息可能由一个函数统一排入消息队列，也有可能是由完成上一个步骤的消息处理函数把触发下一个步骤的消息排入队列。而且，看似单独的用户操作往往会触发几个甚至十几个消息。比如，最简单的鼠标双击在很多系统中都会触发一个鼠标单击和一个鼠标双击事件。考虑到前面提到的情况，处理这两个事件的消息处理函数可能是顺序运行的，也可能是后一个函数间插在第一个函数的运行过程中；而这两个消息处理函数本身还有可能向消息队列排入自己创建的消息，导致更大的不确定性。可以说，今天的消息处理线程本身已经和一个小型操作系统的进程调度模块的复杂度不相上下。本身是单线程，却已经有了多线程的逻辑。

从架构设计的角度看，我们应该尽量通过合理的设计来减少这样的不确定性。但是，从实际看来，很难把这种不确定性降低到能够准确判断一个对象可以在哪行代码的位置被回收的程度。而且，如今的程序要集成不同的 API。这些 API 和消息处理线程集成的方式往往有很大差别，这些差别的细微之处很少被文档完全提及，即使文档完全描述了这些细节，程序员也无法从中分析出两个或者多个不同的 API 集成在一起会发生的所有情况。

每个关于资源回收的 bug 都要根据具体出错的情况，找出原先对回收对象的位置的错误判断，然后找出更合理的回收时机。虽然最后这些 bug 的病症都通过修改回收对象的时机解除了，仍然难以确保没有隐藏的问题。回头看看，在一个拥有垃圾回收的系统中，这些 bug 都不会存在——没有必要耗费精力分析一个对象到底何时可以被安全的回收，当没有人使用它的时候它就会回收。我们关心的其实不是这个对象到底什么时候应该被回收，我们只关心它最终会被回收。一个缺乏垃圾回收的系统让我们不得不玩一场不停回答“什么时候应该被回收”的问题的游戏。

想到这里，我记起当一个激烈批评 Java 的人被问到 Java 是否一无是处的时候，他说 Java 无可争议的积极的历史功绩是把垃圾回收这个概念带回了主流的开发领域。尽管 Java 的垃圾回收最初实现的很不理想，尽管 Java 正在被其它拥有垃圾回收功能语言替代，但是由于它出现的合适时机以及 Sun 在其中所施展的市场手段让它拥有这个荣誉。

如果说推广垃圾回收概念是 Java 的历史功绩。那么没能实现垃圾回收可以说是 C++ 的历史罪责。在提高处理软件复杂度的能力的尝试中，C++ 是认知度最高的，也是在资源消耗上最为节俭的一种尝试。所以 C++ 成了一个标杆——人们开始认为 C++ 有的特性都是大型软件开发必需的，C++ 没有的特性都是大型软件开发可选的——前者就像汽车中的变速箱，是必需的；后者就像自动变速箱，高手是可以不用的。垃圾回收是 C++ 始终不曾具备的特性，但是我开始认为它不是自动变速箱，它是每个大型软件的开发都不可缺少的。抛弃垃圾回收的人认为只是把驾驶的汽车从自动变速换成了手动变速，其实是把一个好的变速箱换成了一个漏油的变速箱。

错失的机会和无用的补救

从 C++ 所处时代的外部环境来说，它有机会引入垃圾回收吗？常常有人用 C++ 出现时的硬件条件来为 C++ 缺少垃圾回收进行辩护。同时代的 Smalltalk 推广的失败，和早期Java 垃圾回收器的糟糕表现为这个说法增加了旁证。

但是，Smalltalk 和 Java 的垃圾回收只是一个特例。像 Eiffel 语言的垃圾回收器的效率证明了垃圾回收完全可以实现的很高效。更重要的是，C++ 没有必要非得实现像 Java 那样基于 root-reach 的使用单独线程的垃圾回收，在硬件条件比较差的时代，一个基于引用计数的垃圾回收器的效率是完全可以接受的。所以，在早期阶段失去引入垃圾回收的机会很难说是一种由于历史原因造成的无奈和必需的牺牲，更像是一个由于短视和偏见造成的错误判断。

C++ 的辩护者的另一个理论是 C++ 是有垃圾回收器的。C++ 既有基于 root-reach 的垃圾回收方案，也有著名的 shared_ptr 来充当基于引用计数的垃圾回收。我认为，这两个机制本身的设计是成功的。（我曾经遇到过一些 bug 用普通的分析很难确定对象应该何时被销毁，其中一些 bug 涉及的指针范围很小，所以我把相关的裸指针全部替换为 shared_ptr 很容易就解决了问题。）但是它们作用在实际中大大降低了，原因在于它们是基于库而不是基于语言的机制。

垃圾回收的内存管理方式需要整个系统的所有模块共同遵守。只要有一个模块放弃了垃圾回收，其它模块的垃圾回收也就名存实亡了。这个原则对于基于引用计数的垃圾回收更为重要。因为基于引用计数的垃圾回收明显在 C++ 使用者中认同率更高，所以这个原则对于 C++ 的垃圾回收也更为重要。由于没有语言强制，当程序复杂度增高，集成的第三方代码来源复杂之后，如果垃圾回收只是一个库而不是一个语言的强制特性的话，系统的开发者和维护者会越来越无力保证所有模块都采用垃圾回收，也没办法避免不同的模块采用实现细节千差万别的垃圾回收。这样整个系统的垃圾回收根本无法作为一个降低复杂度的工具，它本身就成了更大的复杂度的根源。（像上文括号中提到的那类 bug，你并不是总能把所有的裸指针很容易的替换成 shared_ptr。不说有时候你不能获得源代码，就算在获得所有源码的情况下，修改低层库的一个指针的存储方式带来的代码修改量也是不可接受的。）

在这里我们可以把 C++ 的 shared_ptr 和 Objective C 1.0 的引用计数方案做一个比较。从某种意义上说，C++ 的 shared_ptr 更有优势，因为它利用程序的 block scope 来自动实现引用计数的增减，而 Objective C 需要程序员自己通过 retain 和 release 消息来维护引用计数。但是由于 C++ 不强制使用 shared_ptr，从 shared_ptr 中也可以取出裸指针，在复杂程序中只要少部分模块直接使用裸指针或者 delete 操作，就会让 shared_ptr 带来的益处大大降低甚至消失。Objective C 1.0 的方案虽然不能自动增减引用计数，但是由于它是强制性的，保证了它能够真正的降低整个系统的复杂度。

而且，随着硬件水平的提高，基于引用计数的垃圾回收逐渐被淘汰，被基于 root-reach 的垃圾回收取代。C++ 采用裸指针以及把 C++ 对象混同于普通的 C struct 来存储是引入 root-reach 垃圾回收的一大难以克服的障碍。Objective C 也兼容 C，但是它把自己的对象和 C 的元素相对独立开来，让 Objective C 2.0 可以没有太大困难的引入 root-reach 垃圾回收。

结论

一个技术的前景，还要看它的现状。被采用的越多的技术，就越能吸引越多的开发者。技术的推广超过某个临界点就会开始不可逆转的向整个业界渗透的趋势。

在采用垃圾回收的过程中，Mac OS X 走在了前列，它自带的主要应用，以及苹果开发的其它主要软件都是使用具有垃圾回收的 Objective C （包括 1.0 的引用计数）。在 Mac OS X 上用 Python 和 Ruby 等语言写的软件也不少。所以开发 Mac OS X 应用使用垃圾回收已经成为主流。QT、GTK 和 Carbon 反而已经成为边缘。Linux 有许许多多用 Python、Ruby 编写的采用垃圾回收的应用。像 Emacs 这样的风格更是一个传奇——自己独立实现一个带有垃圾回收的解释器。不过用 C++ 编写程序仍然在 Linux 上和拥有垃圾回收的语言分庭抗礼。而Windows是一个荒谬的现象。微软早就在叫嚷 C++ 的消亡。除了企业开发和一些小工具，Windows 上却一个采用垃圾回收的大型应用都不存在。

缺乏垃圾回收决定了 C++ 不是一种适宜大规模软件开发的语言。C++ 的目标——能够比 C 语言能更容易的应对复杂度更高的软件——可以说很大程度上没有达到。漏油的变速箱时常贴贴补补，加加变速油还是可以硬撑的，但是使用它绝对不是一个愉快的体验。另一方面，凭借多年的积累，C++ 在很多平台上拥有基本相似而且开放的实现——这方面其它语言不是支持的平台比较少，就是开放程度不高，所以在某些领域 C++ 的这些资本还可以暂时抵消它的缺点，C++ 还可以用 QT、GTK 这样的形式得到应用。但是我认为 C++ 这些资本的价值也会随着 Python、Objective C 这类语言对更多平台支持的增加（同时，随着那些拒不对垃圾回收提供更好支持和推广的平台的消亡）而逐渐消失。希望软件的内存管理全面的转向垃圾回收。垃圾回收不再是某种语言的特性，而是像函数、文件这样的概念，成为软件开发一个基本的不可缺少的概念。