云风的 BLOG: Effective C++ 3rd 的一点评论

今天终于把作业作完了（可能还有地方要返工），Effective C++ 第 3 版读完了，写了几万字的评论。如我给编辑交稿的 email 里所写：

我觉得评注这个工作比翻译难做。作者细节上讲的非常清楚，大部分地方都不觉得有必要再加注解。我想跟这本书反复写了 10 年有关。所以很多页我都没留评注，真的不知道可以写啥。

编辑原想每页中英分列排版，我是不建议这样的。除了少部分评注，针对个别代码段，或关键词。大部分我的文字都是独立成段的。跟具体原文句子关系不大，只跟篇章段落主题有些许联系。

前几天跟孟岩兄 email 交流，我发了一些稿子给他。他觉得关于本书第一篇 Item 1 : View C++ as a federation of languages ，我的评注还是没有讲透。是的，许多观点还是很难表达清楚。

下面选一段贴出来吧。

Item1 / P11

无人能掌握 C++ 所有的枝节。这并非夸张的说法，也不是藐视读者的智商。因为 C++ 本身就不断在发展，不断的加入新的东西。

很多年之前，我学习 C++ 时用的第一个 C++ 编译器 (Turbo C++ 1.0) 中，template 还只是一个被保留而未被实现任何功能的关键字。就是这个不起眼的小玩意，即使是 C++ 之父，一开始也未能意识到其中蕴涵的巨大能量。可它在 C++ 诞生的若干年后，居然成为了 STL 的基石。

Item1 / P12

C++ 不是绝对意义上的 C++ 。在本书的第二版中没有 Item 1 这一节，而在这一版中，把这一大段放在了第一条，可见作者对这个问题也是逐步认识的。我对此深以为然。这一篇是全书的中心，读此书必须先细细品味它。如果之前读过第二版，对比一下行文风格，就能发现有极大差异。作者不再强调在 C++ 中必须怎样做，文字中隐隐透着些许无奈，本篇是最佳注脚。

在我看来，C++ 各个不同的方面的差异性要远大于它们的共性。C++ 经过几十年发展逐渐演变成今天这样，将如此之多的编程风格糅合在同一门语言中，让它们能和谐共存，是非常困难的事情。它尽可能的去满足各种项目，各种人在各种时期的不同需求。它不是在一开始经过深思熟虑定义出来的。C++ 语言发展到今天，还能发展下去，难能可贵。C++ 新标准从 1998 年到现在，十多年过去了，还未能完全定稿，真的很容易理解。

在某些 C++ 教材上，反复强调不要把 C++ 当成 C 使用（包括本书第二版）。在某种意义上说没错。但只使用 C++ 的一部分：只是 C 的部分，仅仅利用 C++ 的改进来弥补 C 的一些缺陷，在工程实践中也是个不错的方案。如何使用 C++ 最好，仅取决于你的开发团队怎样定义你们使用的 C++ ，并且是否全部认同。Google 在这一点上做的很好，在网络上流传着 google 发布的 C++ 编码规范。有规范、且大家一起遵守之，比到底规范了些什么重要的多。

我在 2005 到 2006 年间，曾经在团队中推广过一段时间类似 C 的 C++ 子集做开发，那和我早些年编写的 C++ 程序风格完全不同，也工作良好。不过这段经历最终使我对面向对象和模板技术做了许多反思，并最终转向彻底的纯 C 开发。

我个人觉得，应该多尝试一些不同的东西，而不要武断的把任何技术当成唯一真理。你可以热爱面向对象，也可以尝试一下 Template 。但需要警惕的是，C++ 虽允许你把各种不同风格的编程方式揉杂在一起使用。每种都提供了高性能的支持。可以取各家之所长，有种世界在我手中的感觉。甚至可以在 C++ 程序员中不断制造出创新的快感。殊不知，其引起的冲突和复杂性，可以轻易超过个人能控制的范畴。仅仅是语言的学习，而不经过长年的经验积累，是很难有切身体会的。尤其是对于聪明之如 C++ 程序员，更是危险。

Item1 / P13

定义你想怎么使用 C++ 非常重要。这决定了你的项目是否能够长时间做下去直到发布。即使你只有一个人，你也会使用别人的代码（至少是标准库），或是提供扩展接口供别人编写扩展。这都会和并非出自你手的代码打交道。即使是所有的一切都是一个人掌握，也不可能随心所欲的使用那些 C++ 中看起来最酷的特性。因为你总会发现 C++ 中还有更有趣的东西能够挖掘。逐渐的，项目会偏离原始的目标，编写 C++ 代码只是为了用 C++ 编写，而非为了解决问题。

Comments

这太酷了。我喜欢你如何把这个页面一起。你做了出色的工作。祝好运。

Posted by: Jenna | (31) July 1, 2014 03:23 PM

看了C++沉思录感觉要想用好用活C++，必须改变自己对编程这个工作的看法，改变解决问题的思维方式，C++的灵魂就是抽象，就像指针是C的灵魂一样，编写代码来解决问题之前先把问题用面向对象技术建模，然后抽象，并考虑怎么用C++特性来表达，感觉跟描述型编程语言相像，比如PROLOG，它们的方法就是先把问题用这个语言的语法描述出来，包括解决问题的方法一起用语言描述出来，编码只是最后的工作而已

Posted by: Patrickjun | (30) November 4, 2011 09:24 PM

以前总是以可以用PASCAL和BASIC自居，在DELPHI的世界里游荡了许久，沉迷于VCL的世界，藐视过MFC，现在呢VCL差不多已死，MFC一家独大，郁闷啊，而对于C++可以说是因为PASCAL而失之交臂了，当时不知看了哪个枪手的文章鼓吹PASCAL的优越性而放弃了继续学习C++的决心，以为会点C就足够了，C++能做的PASCAL一样做得好，现在看来纯粹狗屁，唉，没办法，重头再来学C++吧...

Posted by: Patrickjun | (29) November 4, 2011 09:17 PM

坚持c++的道路

Posted by: 英语翻译机 | (28) February 12, 2011 04:15 PM

不错，有用，谢谢分享

Posted by: 全球译M188 | (27) February 12, 2011 04:13 PM

以前学C++的时候，觉得这是一门高级语言，那时候还是很佩服玩汇编这种NB的。可是现在，在接触了一些更高级的JavaC#和一些web的编程语言后，发现，C++已经变成NB语言了。
以前总是觉得C++没有用好，只是用类来帮我组织程序结构，总是没有用好继承，所以就没有成就感。后来发现一些C++和Java的高手说面向对象中的继承是用处不太大的，主要是范式等，突然释然了一下。不过，我这里垮平台太多，win和linux里面的C++线程函数不一样，确实很烦。

Posted by: howzmh | (26) February 7, 2011 08:44 PM

楼了偶像

Posted by: 深圳SEO | (25) December 19, 2010 03:00 PM

我来凑凑人数。。。多我一个不多吧？？

Posted by: ugg Bailey | (24) November 19, 2010 05:29 PM

c++的const 关键字和类型转换保护这两点无论如何对于c是巨大的进步和优越性。其他复杂的特性确实容易迷惑，不过你可以不用。要让我返回c那是很难接受。最理想是弄一个c++精简版，就留最常用的c++特性。云风大大应该可以试试。

Posted by: fc | (23) November 12, 2010 05:01 PM

面向对象是一种工程构建的方法和具体的语言无关，妄图用语言的面向对象来构建工程的想法出发点就注定了C++这条路并不好走。说的通俗点是把无限的变化投入到语言有限的语法中，小应用的工程还能忍受并且看起来代码还规范很多，大的工程就会让人抓狂。

非常同意

c++是一门学院派语言，说白了，就是作者和几个人在一起，创出来的一门类似simula的c语言，加上妄想一门语言可以完成实际问题域的建模（类，OO，模板），殊不知实际世界关系是如此的复杂，怎么能让你一门语言这么简单的就可以抽象模拟出来出来。

更有一部分，只见树木不见森另的语法元素，例如运算符重载，为了区区几个操作符可以在自定义类型上使用，就引入那么多语法，实际上操作符重载根本就毫无意义。实际的类型其接口多样化，根本不是操作符可以描叙的。

所以，选择一门简约的语言（不那么有野心），使用平凡的心态去学习、使用，精心的设计、编码、测试才是符合项目的发展的之道。

Posted by: softtiger | (22) November 9, 2010 12:50 PM

Posted by: sur | (21) November 6, 2010 06:32 PM

大部分观点还是认同的。我在用C++的时候也是“把着用”。就是收敛着用。但还是在努力地学习它。不是为了能拿出来炫耀，而是不想“在阴沟里帆船”。
现在的语言，都是非常庞大的，学哪个都一样。既然会点C，那就接着学C++吧。

Posted by: Soli | (20) November 4, 2010 01:23 AM

工作3年一直用C++，我也发觉特性太庞杂,特别是模板有些特性还没标准化，一直在发展，开发还要背负许多智力包袱。如果要用，可以以批判的态度来用C++，约束的来用C++。我也想考虑把项目带入C。

Posted by: bookee | (19) October 31, 2010 09:28 PM

Posted by: bookee | (18) October 31, 2010 09:27 PM

C++ 不是绝对意义上的 C++ 。很玄乎，很有古龙的味道

Posted by: Anonymous | (17) October 29, 2010 09:08 PM

翔子也来学习了希望博主有时间到我那里做做！

Posted by: it博客 | (16) October 29, 2010 04:15 PM

尺有所短，寸有所长。
语法糖甜，语法糖苦。

Posted by: 赵中 | (15) October 29, 2010 11:13 AM

曾经弄懂过, 很快就又忘记了....

Posted by: Siney | (14) October 28, 2010 03:39 PM

c++也用了5年多了，一直感觉用得不是很顺手，我一直以为是我个人的问题，比较笨吧？好在2年发现了不仅仅是我会有这样的问题，别人也是，也就坦然了，c++中充满太多的意外，经常给你“惊喜”，现在对于c++，我也就是批判的用用着他了，不会花太多精力去搞花哨的角落技术，对于现成的库，我拿来用即可（不钻研），例如QT,核心我是采用C来编写，或者C风格来写作，c++的思想包袱过重，给人束缚。
话说window平台上面的开发我个人觉得window API + c挺好的，开发速度是满了点（玩具程序），但是对于真正的产品开发来说，这点估计不是什么问题吧？好像云风他们开发程序，连CRT都自己写了呢

Posted by: softtiger | (13) October 28, 2010 11:37 AM

用C++确实有一种世界在我手的感觉。特别在看SGI STL和Boost源代码的时候。不过云老大说的尝试多种语言，我尝试了python，虽然语言特性确实优雅，简单，但是却没有像C++让我成为起死忠的感觉。

Posted by: sld666666 | (12) October 27, 2010 05:03 PM

Posted by: sld666666 | (11) October 27, 2010 05:02 PM

哦！之前在VC中用纯C编译调用DirectX的经历时被引入误区了呢，加上DirectX用起来像用C++类成员函数，我被表象迷惑了。

市面上很多c++讲解的书籍，个人感觉看一大堆那些c++特性的讲解，还不如直接写一段程序看其对应的汇编代码来得深刻。不过看云风的评注甚觉很精彩，是书中难得的亮点，很好看

Posted by: Rainssa | (10) October 27, 2010 03:10 PM

个人观点：
对于C语言开发，半年时间就能把人培养成代码机器，没有太多的个性，无论从命名规范还是多线程并发。有点像打台球或者弹钢琴，熟能生巧，靠的是耐心。
而对于C++来说，每个人写出来的风格都不同，根本原因还是每个人对C++的理解不同。有点像下围棋，段位能分出九等。看自己以前写的C++代码，会哭笑不得；而看高手写的代码，则是一种享受（不是因为负责的技巧，而是因为条理清晰）。
不断提高对C++的理解，多少会有一点成就感，而成就感对于程序员也许就是一切。

Posted by: redhat1982 | (9) October 27, 2010 12:23 PM

DirectX 是基于 COM 的，无所谓 C 还是 C++

Posted by: Cloud | (8) October 27, 2010 11:33 AM

呵呵，云风最近一直用纯C啊！话说MS的DirectX就是C++封装的。

在VC中用纯C无法直接调用DirectX函数，似乎只能每个函数得重新声明函数指针才可调用DirectX函数，真是超麻烦啊！

就开发Windows游戏而言，个人更偏向喜欢OpenGL接口，可惜支持OpenGL驱动的显卡没有DirectX的显卡多

Posted by: Rainssa | (7) October 27, 2010 10:40 AM

看不太懂程序。嗯，不过能够理解那种发掘的快乐。虽然褒义看起来比上一篇日志多了一些，大概要落成铅字的东西，总会更慎重。

Posted by: 夏歌 | (6) October 27, 2010 12:44 AM

膜拜云大大

Posted by: Anonymous | (5) October 26, 2010 06:56 PM

写的不错，基本上所列的这些观点我都认同。