Effective C++ 3rd 的一点评论
source link: https://blogread.cn/it/article/2576?f=hot1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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++ 编写，而非为了解决问题。
Recommend
-
16
Item 85 : Prefer alternatives to Java serialization 优先选择java序列化的备用方法 尽管Java提供了序列化功能，但是却存在潜在的风险和性能问题。 Java的序列化是通过执行 readObject 方法来执行反序列化，这个方法...
-
14
Item 69 : Use exceptions only for exceptional conditions 只在异常情况下使用异常 // Horrible abuse of exceptions. Don't ever do this! int i = 0; while(true)
-
16
Item 57 : Minimize the scope of local variables 最小化局部变量的作用域 在使用的地方声明局部变量，过早的声明会导致代码块过早开始过晚结束； 让方法保持精简，集中于某一些逻辑，如果方法太大分成两个方...
-
10
Item 49 : Check parameters for validity 检查参数合法性 在方法或者是构造器的开始部分作必要的参数合法性检查，可以使用Objects.requireNonNull 或者是断言，断言的一个好处是如果没有开启断言的话对代码是没有任何侵入的...
-
12
Item 42 : Prefer lambdas to anonymous classes 使用lambda表达式来代替匿名类 Collections.sort(words, new Comparator<String>() { public int compare(String s1, String s2) {
-
15
Item 34 : Use enums instead of int constants 使用枚举来代替整型常量 枚举类型添加以前使用常量的方式来满足使用需要，但是这种方式有很多缺点： 无法保证类型安全，并且没有没有表现力（不够优雅）。 常量是...
-
12
Swift unit tests with 3rd party dependencies
-
13
Enterprise Mobility and Enterprise Client Management Blog Long time that...
-
7
TL;DR: a quick run through all the 3rd-party-code that is used in Oryol as of April 2016, and why it was chosen. Small Things These are mostly header/source pairs which are dropped directly into the source d...
-
13
Benchmarks
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK