More Effective C++：35个改善编程与设计的有效方法(中文版)

条款8：了解各种不同意义的 new 和 delete
Understand the different meanings of new and delete
异常（Exceptions）
条款9：利用 destructors 避免泄漏资源
Use destructors to prevent resource leaks.
条款10：在 constructors 内阻止资源泄漏（resource leak）
Prevent resource leaks in constructors.
条款11：禁止异常（exceptions）流出 destructors 之外
Prevent exceptions from leaving destructors.
条款12：了解“抛出一个 exception”与“传递一个参数”
或“调用一个虚函数”之间的差异
Understand how throwing an exception differs from
passing a parameter or calling a virtual function.
条款13：以 by reference 方式捕捉 exceptions
Catch exceptions by reference.
条款14：明智运用 exception specifications
Use exception specifications judiciously.
条款15：了解异常处理（exception handling）的成本
Understand the costs of exception handling.
效率（Efficiency）
条款16：谨记 80-20 法则
Remember the 80-20 rule.
条款17：考虑使用 lazy evaluation（缓式评估）
Consider using lazy evaluation.
条款18：分期摊还预期的计算成本
Amortize the cost of expected computations.
条款19：了解临时对象的来源
Understand the origin of temporary objects.
条款20：协助完成“返回值优化（RVO）”
Facilitate the return value optimization.
条款21：利用重载技术（overload）避免隐式类型转换（implict type conversions）
Overload to avoid implicit type conversions.
条款22：考虑以操作符复合形式（op=）取代其独身形式（op）
Consider using op= instead of stand-alone op.
条款23：考虑使用其他程序库
Consider alternative libraries.
条款24：了解 virtual functions、multiple inheritance、virtual base classes、
runtime type identification 的成本
Understand the costs of virtual functions, multiple inheritance,
virtual base classes, and RTTI.
技术（Techniques, Idioms, Patterns）
条款25：将 constructor 和 non-member functions 虚化
Virtualizing constructors and non-member functions.
条款26：限制某个 class 所能产生的对象数量
Limiting the number of objects of a class.
条款27：要求（或禁止）对象产生于 heap 之中
Requiring or prohibiting heap-based objects.
条款28：Smart Pointers（智能指针）
条款29：Reference counting（引用计数）
条款30：Proxy classes（替身类、代理类）
条款31：让函数根据一个以上的对象类型来决定如何虚化
Making functions virtual with respect to more than one object.
杂项讨论（Miscellany）
条款32：在未来时态下发展程序
Program in the future tense.
条款33：将非尾端类（non-leaf classes）设计为
抽象类（abstract classes）
Make non-leaf classes abstract.
条款34：如何在同一个程序中结合 C++ 和 C
Understand how to combine C++ and C in the same program.
条款35：让自己习惯于标准 C++ 语言
Familiarize yourself with the language standard.
推荐读物
auto_ptr 实现代码
索引（一）（General Index）
索引（二）（Index of Example Classes，Functions，and Templtes）

.　　by value 传值 resolve 决议
　　dereference 解引（i.e. 解参考） parameter 参数 （i.e. 形参）
　　evaluate 评估、核定 type 型别 （i.e. 类型）
　　instance 实例
　　译注：借此版面提醒读者，本书之中如果出现“条款5”这样的参考指示，指的是本书条款5；如果出现“条款E5”这样的参考指示，E 是指 Effective C++ 2/e）
　　

.　　一旦你改用真正支持 bool 的编译器，这种 enum 近似法可能会造成程序行为的改变。
　　另一种做法是利用 typedef 来定义 bool，并以常量对象作为 true 和 false：
　　typedef int bool;
　　const bool false = 0;
　　const bool true = 1;
　　这种手法与传统的 C/C++ 语义兼容。使用这种仿真法的程序，在移植到一个支持有bool 类型的编译器平台之后，行为并不会改变。缺点则是无法在函数重载（overloading）时区分 bool 和 int。以上两种近似法都有道理，请选择最适合你的一种。
　　第二个新性质，其实是4 个转型操作符：static_cast，const_cast，dynamic_cast和reinterpret_cast。如果你不熟悉这些转型操作符，请翻到条款2仔细阅读其中内容。它们不只比它们所取代的 C 旧式转型做得更多，也更好。书中任何时候当我需要执行转型动作，我都使用新式的转型操作符。
　　C++ 拥有比语言本身更丰富的东西。是的，C++ 还有一个伟大的标准程序库（见条款E49）。我尽可能使用标准程序库所提供的 string 类型来取代 char* 指针，而且我也鼓励你这么做。string objects 并不比char*-based 字符串难操作，它们的好处是可以免除你大部分的内存管理工作。而且如果发生 exception 的话（见条款9和10），string objects 比较不会出现 memory leaks（内存泄漏）问题。实现良好的string 类型甚至可和对应的 char* 比赛效率，而且可能会赢（条款29 会告诉你其中的故事）。如果你不打算使用标准的string 类型，你当然会使用类似string 的其他 classes，是吧？是的，用它，因为任何东西都比直接使用 char* 来得好。
　　我将尽可能使用标准程序库提供的数据结构。这些数据结构来自StandardTemplate Library（“STL”——见条款35）。STL包含bitsets，vectors，lists，queues，stacks，maps，sets，以及更多东西，你应该尽量使用这些标准化的数据结构，不要情不自禁地想写一个自己的版本。你的编译器或许没有附带STL给你，但不要因为这样就不使用它。感谢 Silicon Graphics 公司的热心，你可以从 SGI STL网站下载一份免费产品，它可以和多种编译器配合使用。
　　如果你目前正在使用一个内含各种算法和数据结构的程序库，而且用得相当愉快，那么就没必要只为了“标准”两个字而改用 STL。然而如果你在“使用 STL”和“自行撰写同等功能的代码”之间可以选择，你应该让自己倾向使用STL。记得代码的复用性吗？STL（以及标准程序库的其他组件）之中有许多代码是十分值得重复运用的。
　　惯例与术语
　　任何时候如果我谈到 inheritance（继承），我的意思是 public inheritance（见条款E35）。如果我不是指 public inheritance，我会明确地指出。绘制继承体系图时，我对 base-derived 关系的描述方式，是从 derived classes往 base classes 画箭头。例如，下面是条款31的一张继承体系图。
　　
　　这样的表现方式和我在 Effective C++ 第一版（注意，不是第二版）所采用的习惯不同。现在我决定使用这种最被广泛接受的箭头画法：从 derived classes 画往base classes，而且我很高兴事情终能归于一统。此类示意图中，抽象类（abstractclasses，例如上图的 GameObject）被我加上阴影而具体类（concrete classes，例如上图的 SpaceShip）未加阴影。
　　Inheritance（继承）机制会引发“pointers（或 references）拥有两个不同的类型”的议题，两个类型分别是静态类型（static type）和动态类型（dynamic type）。Pointer或 reference 的“静态类型”是指其声明时的类型，“动态类型”则由它们实际所指的对象来决定。下面是根据上图所写的一个例子：
　　GameObject *pgo = // pgo 的静态类型是 GameObject*，
　　new SpaceShip; // 动态类型是 SpaceShip*。
　　Asteroid *pa = new Asteroid; // pa 的静态类型是 Asteroid*，
　　// 动态类型也是 Asteroid*。
　　pgo = pa; // pgo 的静态类型仍然（永远）是 GameObject*，
　　// 至于其动态类型如今是 Asteroid*。
　　GameObject& rgo = *pa; // rgo 的静态类型是 GameObject，
　　// 动态类型是 Asteroid。
　　这些例子也示范了我喜欢的一种命名方式。pgo 是一个 pointer-to-GameObject；pa 是一个 pointer-to-Asteroid；rgo 是一个 reference-to-GameObject。我常常以此方式来为 pointer 和 reference 命名。
　　我很喜欢两个参数名称：lhs 和 rhs，它们分别是“left-hand side”和“right-handside”的缩写。为了了解这些名称背后的基本原理，请考虑一个用来表示分数（rational numbers）的 class：
　　class Rational { ... };
　　如果我想要一个“用来比较两个 Rational objects”的函数，我可能会这样声明：
　　bool operator==(const Rational& lhs, const Rational& rhs);
　　这使我得以写出这样的代码：
　　Rational r1, r2;
　　...
　　if (r1 == r2) ...
　　在调用 operator== 的过程中，r1 位于“==”左侧，被绑定于 lhs，r2 位于“==”右侧，被绑定于 rhs。
　　我使用的其他缩写名称还包括：ctor 代表“constructor”，dtor 代表“destructor”，RTTI 代表 C++ 对 runtime type identification 的支持（在此性质中，dynamic_cast是最常被使用的一个组件）。
　　当你分配内存而没有释放它，你就有了memory leak（内存泄漏）问题。Memoryleaks 在 C 和 C++ 中都有，但是在 C++ 中，memory leaks所泄漏的还不只是内存，因为 C++ 会在对象被产生时，自动调用 constructors，而 constructors 本身可能亦配有资源（resources）。举个例子，考虑以下代码：
　　class Widget { ... }; // 某个 class——它是什么并不重要。
　　Widget *pw = new Widget; // 动态分配一个 Widget 对象。
　　... // 假设 pw 一直未被删除（deleted）。
　　这段代码会泄漏内存，因为pw 所指的Widget 对象从未被删除。如果Widget constructor 分配了其他资源（例如 file descriptors，semaphores，window handles，database locks），这些资源原本应该在 Widget 对象被销毁时释放，而现在也像内存一样都泄漏掉了。为了强调在 C++ 中 memory leaks 往往也会泄漏其他资源，我在书中常以 resource leaks 一词取代 memory leaks。
　　你不会在本书中看到许多 inline 函数。并不是我不喜欢 inlining，事实上我相信 inline 函数是 C++ 的一项重要性质。然而决定一个函数是否应被 inlined，条件十分复杂、敏感，而且与平台有关（见条款E33）。所以我尽量避免 inlining，除非其中有个关键点非使用 inlining 不可。当你在本书中看到一个 non-inline 函数，并不意味我认为把它声明为 inline 是个坏主意，而只是说，它“是否为 inline”与
　　当时讨论的主题无关。
　　有一些传统的 C++ 性质已明确地被标准委员会排除。这样的性质被列于语言的最后撤除名单，因为新性质已经加入，取代那些传统性质的原本工作，而且做得更好。这本书中我会找出被撤除的性质，并说明其取代者。你应该避免使用被撤除的性质，但是过度在意倒也不必，因为编译器厂商为了挽留其客户，会尽力保存向下兼容性，所以那些被撤除的性质大约还会存活好多年。
　　所谓 client，是指你所写代码的客户。或许是某些人（程序员），或许是某些物（classes 或 functions）。举个例子，如果你写了一个 Date class（用来表现生日、最后期限、耶稣再次降临日等），任何使用了这个 class 的人，便是你的 client。任何一段使用了 Date class 的代码，也是你的 clients。Clients 是重要的，事实上
　　clients 是游戏的主角。如果没有人使用你写的软件，你又何必写它呢？你会发现我很在意如何让 clients 更轻松，通常这会导致你的行事更困难，因为好的软件“以客为尊”。如果你讥笑我太过滥情，不妨反躬自省一下。你曾经使用过自己写的 classes或 functions 吗？如果是，你就是你自己的 client，所以让 clients 更轻松，其实就是让自己更轻松，利人利己。
　　当我讨论class templates或function templates，以及由它们所产生出来的 classes或 functions 时，请容我保留偷懒的权利，不一一写出 templates 和其 instantiations（实例）之间的差异。举个例子，如果 Array 是个 class template，有个类型参数T，我可能会以 Array 代表此 template 的某个特定实例（instantiation）——虽然其实Array<T> 才是正式的 class 名称。同样道理，如果swap 是个 function template，有个类型参数 T，我可能会以 swap 而非 swap<T> 表示其实例。如果这样的简短表示法在当时情况下不够清楚，我便会在表示 template 实例时加上 template参数。
　　臭虫报告，意见提供，内容更新
　　我尽力让这本书技术精准、可读性高，而且有用，但是我知道一定仍有改善空间。如果你发现任何错误——技术性的、语言上的、错别字，或任何其他问题——请告诉我，我会试着在本书重印时修正。如果你是第一位告诉我的人，我会很高兴将你的大名记录到本书致谢文（acknowledgments）内。如果你有改善建议，我也非常欢迎。
　　我将继续收集 C++ 程序设计的实效准则。如果你有任何这方面的想法并愿意与我分享，我会十分高兴。请将你的建议、你的见解、你的批评，以及你的臭虫报告，寄至：
　　Scott Meyers
　　c/o Editor-in-Chief, Corporate and Professional Publishing
　　Addison-Wesley Publishing Company
　　1 Jacob Way
　　Reading, MA 01867
　　U. S. A.
　　或者你也可以发送电子邮件到 mec++@awl.com。
　　我整理了一份本书第一次印刷以来的修订记录，其中包括错误修正、文字修润，以及技术更新。你可以从本书网站取得这份记录及与本书相关的其他信息。你也可以通过 anonymous FTP，从 ftp.awl.com 的 cp/mec++ 目录中取得它。如果你希望拥有这份数据，但又无法上网，请寄申请函到上述地址，我会邮寄一份给你。
　　这篇序文够长的了，让我们开始正题吧。