« September 2010 | Main | November 2010 »

October 26, 2010

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++ 编写,而非为了解决问题。

October 19, 2010

Effective C++ 3rd Edition

最近一个多月的业余时间都耗在了《Effective C++ 3rd Edition》这本书上。读的很辛苦,不仅仅是因为这是本英文书。之前答应了博文的编辑帮这本书写评注,将来用于出版。对于要印成白纸黑字的文章,不得不谨慎一些。

我已经有 4 年没有大段时间写 C++ 代码了。中间偶尔有几天写过几千行,其余的 C++ 经验就来至于 google reader 上的阅读。为了读这本书,我又重温了《C++语言的设计和演化》的几个章节。不过整个阅读过程还是不太赏心悦目。

可能还是因为我对 C++ 偏见过多,有如前几年对其的推崇备至。总觉得书里讲的太细,太多观点本是好的,只是局限在了 C++ 语言中。明明是 C++ 的缺陷,却让人绞尽心力的回避那些问题,或是以 C++ 独特的方式回避。在别的语言中不该存在的问题,却成了 C++ 程序员必备的知识。人生苦短,何苦制造问题来解决之。

可这也正映射了本书的主题:有效使用 C++ 。读下去,感觉能懂 Scott Meyers 了。我不相信大牛如厮,写了 10 多年一本书,就没有抱怨的。昨夜,读到 Item 25 ,关于对 std::swap 的扩展问题。109 页引申到特例化 std 名字空间里的方法时。一句“Alas, the form of the prohibition may dismay you” 尽显无奈。

我是上个月初去广州开会的旅途上开读这本书的。当时飞机晚点,在机场耽搁了四个小时。随身带的就这本书和一支铅笔。连同空中的时间,一共六小时。在书上做了几千字的记录。后来在新西兰,晚上边读边记。磨磨蹭蹭的读了几十页。当是把书越读越厚了。

如果不是为了完成先前百般推脱的这个任务,想来是不会这么有耐心的逐字读那些英文句子的。读的越细越发现没啥好评注的。要以我近年对 C++ 的态度。每篇只读个标题,估计就草草翻过了。都是 C++ 程序员必备的知识,还翻来覆去的讲个没完。剩下那些语法细节,属于语言工具相关的知识,不做 C++ 程序员本不必学习了。没太大启发。

结果,评注下来大部分都是对 C++ 的争议。稿子发给编辑看了。说是缺少一些对“初学者解惑和提速”的部分,而“批判固然是好的”,但比例也太大了。而且大部分页面空空,没落任何文字。

我也认为,无论怎样写下文章,都带有现实的局限性。或许过两年想法就变了。但文字印刷出来,就无法更改。如果有多余的精力,可能最后再来过一遍吧。想在出版时加上一篇免责声明,不要因我言论误导,而放弃学习 C++ 。希望不要因为我的评注,影响了书的销量 :)

btw. 如果仔细对比这本书的第二版(我前些年就是读的第二版,侯捷的中译本)和第三版,就会发现这简直是一本新书。