周末出差，去另一个城市给公司的一个项目解决点问题。回程去机场的路上，我用手机上 google reader 打发时间。第一眼就看到孟岩大大新的一篇：Linux之父话糙理不糙 。主题是 C 与 C++ 的语言之争。转到刘江的 blog 下读完了 Linux之父炮轰C++：糟糕程序员的垃圾语言 大呼过瘾。立刻把链接短信发给了几个朋友。
语言之争永远是火药味十足的话题。尤其是 C 和 C++ 的目标市场又有很高的重合性，C++ 程序员往往对C++ 其有着宗教般的虔诚。我想，今天我在自己的 blog 上继续这个战争，一定会换来更多的骂名。只不过这次 Linus 几句话真是说到我心坎里去了，不喊出来会憋坏的 :D
首先，给不熟悉我的朋友做一个技术背景的自我介绍：
我不是一个 Linux 的 fans ，虽然我今天对 Windows 也没有什么好感，但我的大部分工作还是在 WIndows 上做应用软件开发的，对 Windows 还算熟悉。现在我也用非 Windows 的系统，但那是一台 FreeBSD 的机器，不是 Linux 。
我自认为对 C++ 相当熟悉，精读过市面上能买到的关于 C++ 的大部分书籍，像 D&E of C++ 这样的经典还读了不只一遍。用 C++ 写过至少数十万行代码，阅读过 STL 的大部分源码，和 ACE / Boost 的一小部分。
曾经我是 C++ 的忠实粉丝，如果谁说 C++ 的不是，要么会选择跟他辩论到底，要么会对此人不屑一顾。
还有一点我认为非常重要：我第一次爱上 C++ 是 15 年前（1992 年），然后对其慢慢冷淡，回归 C 的怀抱。而到了 2000 年，我又一次爱上 C++ 。也就是说，从热爱 C++ 到否定它，在我的个人经历中，有过两次。不排除未来有第三次的可能，但这一点足可说明，否定 C++ 是出于一种理性的判断，而不是一种冲动。
写上这些，并非是想倚老卖老。我知道，想骂我的 C++ 程序员，更讨厌有人倚老卖老的数落 C++ 的不是。而且论资格，我顶多及的上 Linus 大大的一个零头，既然有老人在前撑腰，下面说话的底气就可以足一些了 :)
C 是 C++ 的一个子集（从 C99 开始已经不是了），用 C 能写出来的代码，C++ 一样可以写出来，然后可以完成的更好。
接下来要找到的问题要点就是，C++ 比 C 多出来那些东西后，真的会带来心智包袱吗？这个问题不好回答。单纯从 C++ 语言特性的繁杂导致的不易掌握和误用这些角度是很难说服我自己的，更别说去说服那些比我聪明的多，刻苦的多的 C++ 程序员们。我自认为对所谓 C++ 的高级特性掌握的还是不错的，并运用在诸多实际项目中。他们相当有趣，在某种程度上也非常的有效。代码可以获得相当高的执行效率，并可以缩短编码的时间（更少的键击数），完成他们也有很大的成就感。
“抽象”，“面向对象”，“设计模式”，这些重要吗？重要。对软件开发相当重要。但重要不是必要，执迷于“抽象”会使你离目标越来越远。当我们一次又一次的提取出事物的共性，建立起抽象层的时候，我们可能丢弃了真实。C++ 继承了 C 语言中“信任程序员”这一设计哲学，致力于让程序员在建立抽象层时，可以不做出额外的消耗。他的解决方式是提供尽可能多的语言工具和设计选择，任何一个都允许你在不用的时候不带来额外的性能损失。
这是一个美好的愿景：C++ 程序员指望可以建立强大的可复用的抽象层，面对世界上一切的具体应用。同时 CPU 执行序列在穿越这个坚厚的抽象层的过程中，居然可以以光速通过（通过抽象层没有额外的执行效率付出）。为此：C++ 社区创造了 STL ，创造了 Boost 。它们共同的关键词是：效率、复用。
使用 C++ 的程序员不断的强调复用性，却不断的需要重写代码。如果一段代码可以不被重写，那多半是因为对重写工程量的妥协。是的，其实我们可以用 C++ 的各种特性写出更好，更漂亮，更高效的代码。两年前的框架不那么完美，不是 C++ 语言的错，是两年前的我能力有限的缘故。但是因为需要改写的是设计框架，这意味着我们必须跟着变更已经完成的功能模块，或是加上桥接层。
的确，STL 和 Boost 都是世界顶尖程序员完成的。代码质量非常的高（当然，我对 Boost 的一部分持保留意见）。我不拿编译器兼容性和可移植性或是编译速度说事，虽然这些的确是现实问题，但不足以成为反对 C++ 基础类库的理由。
好好的用好 C++ 当然得用好 STL ，Boost 也应该认真考察一下。能够仔细读一下源码更好。合格的 C++ 程序员应该做这个。否则作为 C++ 程序员你就违背了 C++ 语言的设计哲学：C++ 信任了你，你就该对的起这种信任，搞清楚你写的每一行代码背后，机器都去干了什么。
但是，STL 过于庞大了，Boost 更加是。我不是抱怨阅读和学习它们的源码的难度和需要的时间和精力。正相反，我在学习它们的过程中充满了乐趣和感激之情。高手前辈透过这些高质量的代码教会了我很多东西。我隐隐担心的是，这么庞大的代码，它的设计不可能是永远正确的。两年之后，他们的设计肯定依旧正确，再两年还是的。但是我几乎敢肯定，放之更长远的时间来看，绝对会在某些设计领域发现其不是最佳的选择。到那一天，我们会选择修改吗？我想 C++ 社区会被迫选择妥协。但是，C++ 程序员心中会充满痛苦。
C 在这个问题上的抉择是不一样的。在效率问题上，C 程序里最令人担心的是函数调用的消耗。C++ 程序员最津津乐道的案例就是 std::sort 全面击败了 C 库中的 qsort 。C 语言的失败正在于多余的函数调用消耗。
但是，从一开始 C 就选择了承认函数调用的消耗，而这一点几乎是唯一。付出了这个代价后，设计失误导致的效率下降问题几乎总可以避免。C 和 C++ 都可以选择重写设计失败的部分，但不一样的是， C 程序员几乎可以不考虑妥协的问题。同样的是考虑极端效率的语言，C 语言坦然面对缺陷，才是真正的符合了 KISS 原则。
我对这个问题的见解，可以再引用 Linus 的一段话作为收场。“如果你想用更花哨的语言，C++绝对是最糟糕的选择。如果想要真正的高级特性，那就选择有垃圾回收或者好的系统集成的，而不是既缺乏C的简约（sparseness）又缺乏C的直接而且没有重要概念的高层绑定（high-level bindings to important concepts）的东西。”。这是我最近几年来一直坚持的观点：C++ 的发展，一定要补充对 GC 支持所需要的特性。
强调一下，我并不讨厌 C++ :) 。 C++ 的粉丝们可以随便骂我，但是不要带上阶级仇恨。
ps. 最近两年多，我在做一个游戏引擎的项目。这个项目现在是第三个版本了。第一个版本是用 C++ 实现的，但是没有用任何已存在的类库（包括 STL）。在第二个版本中，我去掉了所有使用 C++ 高级特性实现的部分，只使用了 C++ 基本特性实现所有。今年重写的第三个版本，全部换成 C 代码了。这个项目的发展，可以反应出我个人对 C/C++ 理解的心路过程。