今天终于把作业作完了（可能还有地方要返工），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++ 编写，而非为了解决问题。
[103] 