1、如何学好 C+，我没有别的办法给你们，唯一的办法就是读书，读大量的书，就可以解决。要把 C+作为日常语言，而不是一种程序语言，这样就好办了。 有人又要问我，那么我应该读什么书才好？没有时间怎么办？ 我只能对你们说，没时间的话，就别学 C+了，做你们喜欢做的事。生活中没有C+，也同样美好。 如果你准备学，一定要学好，那么我开个书单，应该问题不是甚大。 首先肯定要读一读 Bjarne Stroustrup 的 The Design and Evolution of C+，了解一下这个语言的历史。接下来就可以看别的书了，但要不停地回头看这本书，看到你不断地学到的新技术是怎么样一点点地被接纳到这个语言
2、中去的。 第一本书因人而异，基础好一些的，可以看 Stanley B. Lippman 的 C+ Primer，这本书非常地巨大，你打星号的部分可以不要看。基础不太好的，可以看 Stanley B.Lippman 的 Essential C+，这本书份量要轻得多，不过四个 C+的范型都讲了，而且讲得非常清楚。 第二本应该停止技术层面的东西，静下心来看看 Pike 和 Kernighan 的 The Practice of Programming，好好地整理一下，在程序设计中应该有哪些注意的事项。这本非常薄的 booklet，可以说是程序员必读的指南。 第三本书，就应该是 Bruce Eckel
3、 写的、候捷译的 Thinking in C+，这本书每过半年我就要重读一遍。可以说每一章都是写得发人深省的，这本书让我感觉到了技术运用的非常高的境界，但是语言非常平实，只要认真地读，即使基础不行，也一定可以懂。我在教课的时候，就是用这本书（面对的学生是零基础）。要更上一层的话，就要慢一步，先要把握 C+设计习惯的良好。这是 Scott Meyers Effective C+和 More Effective C+带给我们的无尽收益。我 More Effective C+买不起，只好花了 10 块钱复印装订了一本“线装本“ ，看起来像葵花宝典（;-)）。这两本书是真正的经典，作者对 C+的纯熟，
4、使得语言的风格读起来简直是如饴甘甜，就像他站在对面在讲课。我手中有这两本书的原版 CD，如果有兴趣，可以发 E-mail 到 或在饮水思源投条儿给 gaobo 索要，只要您提供光盘我就给免费烧。如果你已经深刻地理解了 Effective C+和 More Effective C+，那你可以发现，你在众人中已经是鸡群之鹤。可以指导项目运作了，可以编写一切你想做的程序了，可以指出别人看起来不错的代码的大小问题了。如果你能一眼看出有人的代码是对应于“条款 27“或“条款 M6“，那你可真是让本人刮目了。 我已经讲了，如果要写程序，EC+和 MEC+的境界已经足以使你自如应付，可是如果你还不满足，想
5、关注一些理论层面的问题，或是想看看实现的代码，你就不应该错过这几本好极了的书。我是说 Herb Sutter 的 Exceptional C+和 More Exceptional C+，这两本书的难度是非常大的，我对每一条的阅读笔记都是十多页。特别是泛型程序设计的部分，这两本书旁征博引，极尽深入探讨之能事，每每看懂一条，都抹汗一次，大感酣畅淋漓；还有侯捷的 STL 源码剖析 ，以实际的例子一点点地讲解一个 STL 是怎么样实现的，我是刚开始读，不发表评论；而Stanley B. Lippman，Cfront 的实现者之一，执笔写出 Inside the C+ Object Model，我只有一
6、个字，就是基本帅呆了。我从中了解了无数的编译器解释源代码的细节，以及记忆体分配的细节，呵呵，这些都知道了，我还怕什么呢？最近得到了另一Cfront 实现者、C+标准委员会 Koenig 的 C+ 沉思录，看起来非常不错，这里也推荐给大家，但我也没看完，亦无发言权。 最后最后，你们，未来的 C+理论家们，可要记住，Bjarne Stroustrup 的 The C+ Programming Language 无论如何也应该读个四五遍！这是一切 C+的书本的源泉。如果还觉得不够，就向 C+标准委员会订购一本 C+标准。一切中国大陆作者的书，一概不要看（包括我的）。一切 VC+或讲特定的编译器的书，
7、一概不要看。如果需要补 C 语言的课，买一本非常小的 K / Standard C+ stylecin s;而不是这样的：char sMAX; /* Standard C style */scanf(“%s“,s);去看看那些扎实的 C+程序员们推荐的书吧。记住，没有哪本书对所有人来说都是最好的。另外，要写地道的 C+程序，而避免用 C+的语法写传统风格的程序，新瓶装旧酒没多大意义。（遗憾的是，目前在市面上的中文 C+教材中，符合 B. S 的这个标准的可以说一本都没有，大家只好到网上找一些英文的资料来学习了。译者）6. 怎样改进我的 C+程序？不好说。这取决于你是怎么使用该语言的。大多数人低
8、估了抽象类和模板的价值，反过来却肆无忌惮地使用造型机制(cast)和宏。这方面可以看看我的文章和书。抽象类和和模板的作用当然是提供一种方便的手段建构单根的类层次或者重用函数，但更重要的是，它们作为接口提供了简洁的、逻辑性的服务表示机制。7. 语言的选择是不是很重要？是，但也别指望奇迹。很多人似乎相信某一种语言能够解决他们在系统开发中遇到的几乎所有问题，他们不断地去寻找完美的编程语言，然后一次次的失败，一次次的沮丧。另外一些人则将编程语言贬为无关紧要的细节，把大把大把的银子放在开发流程和设计方法上，他们永远都在用着 COBOL, C 和一些专有语言。一种优秀的语言，例如 C+，能帮助设计者和程序
9、员做很多事情，而其能力和缺陷又能够被清楚地了解和对待。8. ANSI/ISO 标准委员会是不是糟蹋了 C+？当然不是！他们（我们）的工作很出色。你可以在一些细节上找些歪理来挑刺，但我个人对于这种语言以及新的标准库可是欣欣然。ISO C+ 较之 C+的以前版本更出色更有条理。相对于标准化过程刚刚开始之初，你今天可以写出更优雅、更易于维护的 C+程序。新的标准库也是一份真正的大礼。由于标准库提供了 strings, lists, vectors, maps 以及作用于其上的基本算法，使用 C+的方式已经发生了巨大的变化。9. 你现在有没有想删除一些 C+特性？没有，真的。问这些问题的人大概是希望我
10、回答下面特性中的一个：多继承、异常、模板和 RTTI。但是没有它们，C+ 就是不完整的。在过去的 N 年中，我已经反复考虑过它们的设计，并且与标准委员会一起改进了其细节，但是没有一个能被去掉又不引起大地震。从语言设计的角度讲，我最不喜欢的部分是与 C 兼容的那个子集，但又不能把它去掉，因为那样对于在现实世界里工作的程序员们来说伤害太大了。C+与C 兼容，这是一项关键的设计决策，绝对不是一个叫卖的噱头。兼容性的实现和维护是十分困难的，但确实使程序员们至今受益良多。但是现在，C+已经有了新的特性，程序员们可以从麻烦多多的 C 风格中解脱出来。例如，使用标准库里的容器类，象 vector, list
11、, map, string 等等，可以避免与底层的指针操作技巧混战不休。10. 如果不必和 C 兼容，你所创造的语言是不是就会是 Java?不是，差得远。如果人们非要拿 C+和 Java 来作比较，我建议他们去阅读The Design and Evolution of C+，看看 C+为什么是今天这个样子，用我在设计C+时遵从的原则来检验这两种语言。这些原则与 SUN 的 Java 开发小组所持的理念显然是不同的。除了表面语法的相似性之外，C+与 Java 是截然不同的语言。在很多方面，Java 更像 Smalltalk（译者按：我学习 Java 时用的是 Sun 的培训教材，里面清楚地写道：
12、Java 在设计上采用了与 C+相似的语法，与 Smalltalk 相似的语义。所以可以说 Java 与 C+是貌合神离，与 Smalltalk 才是心有灵犀）。Java 语言相对简单，这部分是一种错觉，部分是因为这种语言还不完整。随着时间的推移，Java 在体积和复杂程度上都会大大增长。在体积上它会增长两到三倍，而且会出现一些实现相关的扩展或者库。这是一条每个成功的商业语言都必须走过的发展之路。随便分析一种你认为在很大范围内取得了成功的语言，我知道肯定是无有例外者，而且实际上这非常有道理。上边这段话是在 Java 1.1 推出之前写的。我确信 Java 需要类似模板的机制，并且需要增强对于固
13、有类型的支持。简单地说，就是为了基本的完整性也应该做这些工作。另外还需要做很多小的改动，大部分是扩展。1998 年秋，我从 James Gosling（Java 语言的创始人 译者）那里得到一份建议书，说是要在 Java 中增加固有类型、操作符重载以及数学计算支持。还有一篇论文，是数学分析领域的世界级大师，伯克利大学的 W. Kahan 教授所写的 How Javas Floating-Point Hurts Everyone Everywhere（“且看 Java 的浮点运算如何危害了普天下的芸芸众生”译者），揭露了 Java 的一些秘密。我发现在电视和出版物中关于 Java 的鼓吹是不准确
14、的，而且气势汹汹，让人讨厌。大肆叫嚣凡是非 Java 的代码都是垃圾，这是对程序员的侮辱；建议把所有的保留代码都用 Java 重写，这是丧心病狂，既不现实也不负责任。Sun 和他的追随者似乎觉得为了对付微软罪恶的“帝国时代”，就必须如此自吹自擂。但是侮辱和欺诈只会把那些喜欢使用不同编程语言的程序员逼到微软阵营里去。Java 并非平台无关，它本身就是平台。跟 Windows 一样，它也是一个专有的商业平台。也就是说，你可以为 Windows/Intel 编写代码，也可以为 Java/JVM 编写代码，在任何一种情况下，你都是在为一个属于某个公司的平台写代码，这些代码都是与该公司的商业利益扯在一起
15、的。当然你可以使用任何一种语言，结合操作系统的机制来编写可供 JVM 执行的程序，但是 JVM 之类的东西是强烈地偏向于Java 语言的。它一点也不像是通用的、公平的、语言中立的 VM/OS。私下里，我会坚持使用可移植的 C+作大部分工作，用不同的语言作余下的工作。（”Java is not platform-independent, it is the platform”，B. S 的这句评语对于 C+用户有着很大的影响，译者在国外的几个新闻组里看到，有些 C+高手甚至把这句话作为自己的签名档，以表明对 Java 的态度和誓死捍卫 C+的决心。实际上有很多程序员不光是把自己喜爱的语言当成一种
16、工具，更当成一种信仰。译者）11. 您怎么看待 C#语言？就 C#语言本身我没什么好说的。想让我相信这个世界还需要另外一个专有的语言可不是一件容易的事，而且这个语言还是专门针对某一个专有操作系统的，这就更让我难以接受。直截了当地说，我不是一个专有语言的痴迷者，而是一个开放的正式标准的拥护者。12. 在做大项目时，您是不是真的推荐 Ada，而不是 C+？当然不是。我不知道这是谁传出来的谣言，肯定是一个 Ada 信徒，要么是过分狂热，要么是不怀好意。13. 你愿不愿意将 C+与别的语言比较？抱歉，我不愿意。你可以在 The Design and Evolution of C+的介绍性文字里找到原因
17、。有不少书评家邀请我把 C+与其它的语言相比，我已经决定不做此类事情。在此我想重申一个我很久以来一直强调的观点：语言之间的比较没什么意义，更不公平。主流语言之间的合理比较要耗费很大的精力，多数人不会愿意付出这么大的代价。另外还需要在广泛的应用领域有充分经验，保持一种不偏不倚、客观独立的立场，有着公正无私的信念。我没时间，而且作为 C+的创造者，在公正无私这一点上我永远不会获得完全的信任。人们试图把各种语言拿来比较长短，有些现象我已经一次又一次地注意到，坦率地说我感到担忧。作者们尽力表现的公正无私，但是最终都是无可救药地偏向于某一种特定的应用程序，某一种特定的编程风格，或者某一种特定的程序员文化
18、。更糟的是，当某一种语言明显地比另一种语言更出名时，一些不易察觉的偷梁换柱就开始了：比较有名的语言中的缺陷被有意淡化，而且被拐弯抹角地加以掩饰；而同样的缺陷在不那么出名的语言里就被描述为致命硬伤。类似的，有关比较出名的语言的技术资料经常更新，而不太出名的语言的技术资料往往是几年以前的，试问这种比较有何公正性和意义可言？所以我对于 C+之外的语言的评论严格限制在一般性的特别特定的范畴里。换言之，我认为 C+是大多数人开发大部分应用程序时的最佳选择。14. 别人可是经常拿他们的语言与 C+比来比去，这让你感到不自在了吗？当这些比较不完整或者出于商业目的时，我确实感觉不爽。那些散布最广的比较性评论大
19、多是由某种语言，比方说 Z 语言的拥护者发表的，其目的是为了证明Z 比其它的语言好。由于 C+被广泛地使用，所以 C+通常成了黑名单上的头一个名字。通常，这类文章被夹在 Z 语言的供货商提供的产品之中，成了其市场竞争的一个手段。令人震惊的是，相当多的此类评论引用那些在开发 Z 语言的公司中工作的雇员的文章，而这些经不起考验文章无非是想证明 Z 是最好的。特别是在这些比较中确实有一些零零散散的事实，（所以更具欺骗性译者），毕竟没有一种语言在任何情况下都是最好的。C+当然不完美，不过请注意，特意选择出来的事实虽然好像正确，但有时是完全的误导。以后再看到语言比较方面的文章时，请留心是谁写的，他的表述
20、是不是以事实为依据，以公正为准绳，特别是评判的标准是不是对于所引述的每一种语言来说都公平合理。这可不容易做到。15. 在做小项目时，C 优于 C+吗？我认为非也。除了由于缺乏好的 C+编译器而导致的问题之外，我从没有看到哪个项目用 C 会比用 C+更合适。（不过现在 C+编译器导致的问题还是不可忽略的，当你看到同样功能的C+程序可执行代码体积比 C 大一倍而且速度慢得多时，会对此有所感触的。译者）以下内容来自 Visual C+ Developers Journal 主编 Elden Nelson 2000 年 3月对 B. S 的专访16. 如果您现在有机会从头设计 C+语言，您会做些什么不
21、同的事情？当然，你永远都不可能重新设计一种语言，那没有意义，而且任何一种语言都是它那个时代的产物。如果让我今天再设计一种语言，我仍然会综合考虑逻辑的优美、效率、通用性、实现的复杂程度和人们的喜好。要知道人们的习惯对于他们的喜好有着巨大的影响。现在，我会寻找一种简单得多的语法，我会把类型系统的冲突问题限制在很少的几种情况里，而且你能很容易的发现这些问题。这样就能够很容易的禁止不安全的操作。（B. S 的原则是：对于糟糕的代码，就算是不能完全禁止，至少也要让它大白于天下，而不是藏在阴暗的角落里暗箭伤人。C+实际上已经提供了这样的机制，例如如果你使用象 reinterpret_cast(pointe
22、r)这样的很明显是非常糟糕的表达式进行造型，别人会很容易地找到问题所在。只不过 C+仍然允许你使用传统的、C 风格的造型机制，而又有不少人一直使用这种老式的风格，所以才引来麻烦多多。B. S 的意思是说，要是现在能够禁止老式的风格该有多好！作为语言设计者的他，恐怕是没有这个机会了，但是作为语言使用者的我们，却还有很大的希望去改进自己的代码。何去何从，应该是我们深思的时候了。译者）我还会把核心语言的体积尽可能搞得小一些，包括类和模板的关键的抽象特性，而把很多其它的语言特性放在库里来解决。当然我也会保证核心语言足够的强大，使得那些库本身也足以用这个核心语言来产生。我可不希望标准库的创建需要用到什么
23、不属于该语言本身的神秘机制。另外我会让这个核心语言的定义更加精确。（有不少新的语言在建库时就使用了一些“不属于该语言本身的神秘机制”，比如VB 和 JAVA。从理论上讲，这是近乎无赖的行径，所以 B. S 不以为然。不过从实用出发倒也无伤大雅。译者）最重要的是，我会在该语言被广泛使用之前尽可能维持一个很长的酝酿期，这样我可以以其他人的反馈为基础进行改进。这可能是最困难的，因为一旦有什么东西是明显出色和有前途的，大家就会蜂拥而至的来使用它，此后作任何不兼容的修正都会是非常困难的。我相信这些思想与我当初设计 C+时的理念是非常类似的，同样也是这些思想指引着一二十年来 C+的不断演化。当然，我认为现
24、在还没有什么东西能让我觉得像是“完美的语言”。17. 您预期 C+做哪些增强，会不会删掉一些东西？很不幸，虽然有一些东西很应该扔掉，但恐怕很难真的删掉任何东西。第一个应该抛弃的东西就是 C 风格的造型机制和类型截断转换。就算不禁止，编译器的作者们至少也应该对这种行为给与强烈的警告。我希望能用类似 vector 的东西彻底取代数组，但这显然是不肯能的。不过如果程序员们能主动使用 vector 来代替数组，就会立刻受益匪浅。关键是你不必再使用 C+中最复杂难缠的技巧了，现在有优秀得多的替代方案。至于主要的特性，我没想去掉任何东西。特别是那些把 C+与 C 区别开来的主要特性恐怕没法风平浪静的被抛掉
25、。通常问这些问题的人是希望我挑出诸如多继承、异常、模板等机制来接受批判。所以在这我想大声讲清楚，我认为多继承机制对于静态类型语言实现继承性来说是必需的，异常机制是在大系统中对付错误的正确方法，模板机制是进行类型安全的、精致的和高效的程序设计的灵丹妙药。我们可以在小的细节上对于这些机制挑挑刺，但在大的方面，这些基本的概念都必须坚持。现在我们仍在学习标准 C+，也正在标准所提供的特性基础上发展出更新的、更有趣的编程技术。特别是人们刚刚开始使用 STL 和异常机制，还有很多高效强大的技术鲜为人知，所以大可不必急匆匆的跑去增加什么新的机制。我认为当前的重点是提供很多新的、比以前更加精致的、更有用的库，这方面潜力巨大。例如，如果有一个能被广泛使用的、更精致的支持并发程序设计的库，那将是一大福音C 风格的线程库（例如 Pthread译者）实在不够好。我们也就可以与各种其他的系统，例如 SQL 以及不同的组件模型更好地契合起来。数值计算领域的人们在这方面好像已经走在了前面，类似像Blitz+、POOMA、MTL 之类的高效而精致的库的开发已经取得了非凡的成就。（译者在 Internet 上造访了 Blitz+和 POOMA 的主页，前者是一个高性能数学库，
