不得不看的两次从C++回归C的高手评论C++

语言之争永远是火药味十足的话题。尤其是C和C++的目标市场又有很高的重合性，C++程序员往往对C++有着宗教般的虔诚。我想继续这个战争，一定会换来更多的骂名。只不过这次Linus几句话真是说到我心坎里去了，不喊出来会憋坏的。

Linux之父炮轰C++：糟糕程序员的垃圾语言
Linux之父话糙理不糙	不得不看的两次从C++回归C的高手评论C++	C语言是否该扔进垃圾桶
为什么每个程序员都应该学习C语言？	每个程序员都应该学习C语言？我可不这么认为	C语言已经死了，5个需要忘却它的理由
用C设计 用C++编码	为什么使用C++	C++0x：崭新的C++，还是另一个Java？
编程语言的三大定理	动态语言为何难堪重任	动态语言面面观

【引自云风 的博客】首先，给不熟悉我的朋友做一个技术背景的自我介绍：

我不是一个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++一样可以写出来，然后可以完成的更好。

这是新手们自以为是的攻击武器。Linus用了一个很恰当的理由做出反击：“你当然可以用任何语言编写糟糕的代码。但是，有些语言，尤其是带有一些心智（mental）包袱的语言本身就非常糟糕。 ”

没错，我最想说的就是这个。C++就是一个“带有一些心智（mental）包袱的语言” 。这对软件设计的影响非常之大，没有经年的软件开发实践很难理解这一点。

从这一点上展开，把ASM和C比较的问题和C与C++的比较相提并论就没有意义了。

接下来要找到的问题要点就是，C++比C多出来那些东西后，真的会带来心智包袱吗？这个问题不好回答。单纯从C++语言特性的繁杂导致的不易掌握和 误用这些角度是很难说服我自己的，更别说去说服那些比我聪明的多，刻苦的多的C++程序员们。我自认为对所谓C++的高级特性掌握的还是不错的，并运用在 诸多实际项目中。他们相当有趣，在某种程度上也非常的有效。代码可以获得相当高的执行效率，并可以缩短编码的时间（更少的点击数），完成他们也有很大的成 就感。

好了，让我再引用Linus的一句说到我心坎里的话。“字符串/内存管理根本无关紧要。这不是重要的部分，而且也不复杂。唯一真正重要的部分是设计。”

设计！这才是重中之重。

如果要说，这最近10年的程序员生涯我学会了什么？我认为，我比以前能设计出更好的代码了。能更准确的把握设计的坏味道。而对编程语言的掌握，对操作系统的熟悉，工作相关知识的了解等等。那些只是自然而然发生的事，那些是知识的积累，而非能力的提高。

“抽象”，“面向对象”，“设计模式”，这些重要吗？重要。对软件开发相当重要。但重要不是必要，执迷于“抽象”会使你离目标越来越远。当我们一次 又一次的提取出事物的共性，建立起抽象层的时候，我们可能丢弃了真实。C++继承了C语言中“信任程序员”这一设计哲学，致力于让程序员在建立抽象层时， 可以不做出额外的消耗。他的解决方式是提供尽可能多的语言工具和设计选择，任何一个都允许你在不用的时候不带来额外的性能损失。

这是一个美好的愿景：C++程序员指望可以建立强大的可复用的抽象层，面对世界上一切的具体应用。同时CPU执行序列在穿越这个坚厚的抽象层的过程 中，居然可以以光速通过（通过抽象层没有额外的执行效率付出）。为此：C++社区创造了STL，创造了Boost。它们共同的关键词是：效率、复用。

再往上呢？另一个问题产生了：“——低效的抽象编程模型，可能在两年之后你会注意到有些抽象效果不怎么样，但是所有代码已经依赖于围绕它设计的‘漂 亮’对象模型了，如果不重写应用程序，就无法改正。”这一段依旧是Linus语，我不停的引用，是因为我明白这一点，但是不能表达的更清楚。

使用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++。

ps.最近两年多，我在做一个游戏引擎的项目。这个项目现在是第三个版本了。第一个版本是用C++实现的，但是没有用任何已存在的类库（包括 STL）。在第二个版本中，我去掉了所有使用C++高级特性实现的部分，只使用了C++基本特性实现所有。07年重写的第三个版本，全部换成C代码了。这 个项目的发展，可以反应出我个人对C/C++理解的心路过程。

【相关文章】

• Linux之父炮轰C++：糟糕程序员的垃圾语言

• Linux之父话糙理不糙

• 未来几年动态语言谁将成为主流