最近闲来无事，想起了之前买的《Effective C++（第三版）》这本书，就打算看一下。

书中介绍了改善程序与设计的 55 个具体做法，但本文并不会像书中那样对相关问题进行分析，而是直接给出结论和重点（个别也会简单解释）。

如果你在阅读此文章，那么我认为，在大部分场景下，你可以直接采用这些结论，因为不满足这些结论的情况是比较少的。但如果你有时间，还是建议阅读原书，理解这些结论从何而来，以及在哪些情况下可能不适用。

另外，由于我读此书时已经是 2023 年，C++ 标准已经到了 23，而此书是依据 98/03 标准编写的，所以本文中我会将部分过时内容替换为新内容。我替换了的部分会在对应位置做出标注或解释。

下面的笔记顺序，与原书的结构顺序一致，每个做法称为一个“条款”。

1. 让自己习惯 C++

条款 01：将 C++ 视为一个语言联邦

  • C++ 高效编程守则视状况而变化，取决于你使用 C++ 的哪一部分。

作者认为 C++ 可以视为一个由相关语言组成的联邦，而非单一语言。在其某个次语言(sublanguage)中，各种守则与通例都倾向简单、直观易懂、并且容易记住。当我们由一个次语言换到另一个次语言的时候，守则可能会改变。这里的守则和通例我理解为一些编程方法、技巧、倾向性（比如两种方案都能实现目标，那么更应当选择哪个方法）等。

作者划分的次语言共有四个：

  1. C part of C++ ：即 C++ 仍是以 C 为基础的，这里指的就是采用 C 语言编程的部分。
  2. Object-Oriented C++ ：即 C with Classes，包含 class 的各种特性。
  3. Template C++ ：C++ 的泛型编程部分。
  4. STL ：STL 是个 template 程序库，其有自己特殊的办事方式，当我们使用 STL 时需要遵守它的规约。

记住这四个次语言，当你从某个次语言切换到另一个，可能会导致高效编程守则要求你改变策略。例如对内置（也就是 C-like）类型而言 pass-by-value 通常比 pass-by-reference 高效，但当你从 C part of C++ 移往 Object-Oriented C++， 由于用户自定义(user-defined)构造函数和析构函数的存在，pass-by-reference-to-const 往往更好。运用 Template C++ 时尤其如此，因为彼时你甚至不知道所处理的对象的类型。然而一旦跨入 STL 你就会了解，迭代器和函数对象都是在 C 指针之上塑造出来的，所以对 STL 的选代器和函数对象而言，旧式的 C pass-by-value 守则再次适用（参数传递方式的选择细节请见条款 20）。

条款 02：尽量以 const, enum, inline 替换 #define

  • 对于单纯常量，最好以 const 对象或 enum 替换 #define。
  • 对于形似函数的宏(macros)，最好改用 inline 函数替换 #define。

这个条款也可以改为“宁可以编译器替换预处理器”，即核心思想是多让编译器做事，少让预处理器做事（#define 是由预处理处理的）。

条款 03：尽可能使用 const

  • 将某些东西声明为 const 可帮助编译器侦测出错误用法。const 可被施加于任何作用域内的对象、函数参数、函数返回类型、成员函数本体。
  • 编译器强制实施 bitwise constness，但你编写程序时应该使用“概念上的常量性(conceptual constness)” 。
  • 当 const 和非 const成员函数有着实质等价的实现时，令非 const 版本调用 const 版本可避免代码重复。

条款 04：确定对象被使用前已先被初始化

  • 为内置型对象进行手工初始化，因为 C++ 不保证初始化它们。

  • 构造函数最好使用成员初值列(member initialization list)，而不要在构造函数本体内使用赋值操作(assignment)。初值列列出的成员变量，其排列次序应该和它们在class中的声明次序相同。

  • 为免除“跨编译单元之初始化次序”问题，请以 local static 对象替换 non-local static 对象。

2. 构造/析构/赋值运算

条款 05：了解 C++ 默默编写并调用哪些函数

  • 编译器可以暗自为 class 创建默认构造函数、拷贝构造函数、拷贝赋值操作符、移动构造函数、移动赋值运算符，以及析构函数。

注：移动构造函数和移动赋值运算符是我自己加上的。这俩移动构造 C++ 11 标准加入的，而本书是基于 C++ 98/03 标准编写的，所以稍显落后。

条款 06：若不想使用编译器自动生成的函数，就该明确拒绝

  • 为阻止编译器自动（暗自）提供的机能，可在相应的成员函数声明时添加 = delete。

原文提供的方法已经过时，这里就没有写出了。

条款 07：为多态基类声明 virtual 析构函数

  • 具备多态性的基类应该声明一个 virtual 析构函数。如果一个 class 带有任何 virtual 函数，那么它就应该拥有一个 virtual 析构函数。
  • 一个 class 的设计目的如果不是作为基类使用，或不是为了具备多态性，就不该用 virtual 析构函数。

条款 08：别让异常逃离析构函数

  • 析构函数绝对不要抛出异常。如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然后吞掉（不传播）这些异常或结束程序。
  • 如果需要对某个操作函数运行期间抛出的异常做出反应，那么 class 应该提供一个普通函数执行该操作，而非在析构函数中。

条款 09：绝不在构造和析构过程中调用 virtual 函数

  • 在构造和析构期间不要调用 virtual 函数，因为这类调用不会下降到派生类（比起当前执行构造函数和析构函数那层）。

条款 10：令 operator= 返回一个 *this 的引用

  • 令赋值操作符返回一个 *this 的引用。

条款 11：在 operator= 中处理“自我赋值”

  • 确保当对象自我赋值时 operator= 有良好行为。其中技术包括比较“源对象”和“目标对象”的地址、精心周到的语句顺序、以及 copy-and-swap。
  • 确定任何函数如果操作一个以上的对象，而其中多个对象是同一对象时，其行为仍然正确。

条款 12：复制对象时勿忘其每一个成分

  • 拷贝函数应该确保复制“对象内所有的成员变量”及“所有基类的成分”。
  • 不要尝试以某个拷贝函数实现另一个拷贝函数。应该将共同机能放进第三个函数中，并由两个拷贝函数共同调用。

3. 资源管理

条款 13：以对象管理资源

  • 为防止资源泄漏，请使用 RAII 对象，它们在构造函数中获得资源并在析构函数中释放资源。
  • 两个常被使用 RAII 的类分别是 std::shared_ptr 和 std::unique_ptr。前者的拷贝行为比较直观。若选择 std::unique_ptr，移动动作会使它（被复制者）不再可用。

我对这里第二点做过修改，原文提到的是 tr1::shared_ptr 和 auto_ptr。前着已经纳入标准库，即为 std::shared_ptr。后者已经弃用。取而代之的是 std::unique_ptr。

条款 14：在资源管理类中小心 copy 行为

  • 复制 RAII 对象必须一并复制它所管理的资源，所以资源的拷贝行为决定 RAII 对象的拷贝行为。
  • 普遍而常见的 RAII 类的拷贝行为是：抑制拷贝、施行引用计数法。不过其他行为也都可能被实现。

条款 15：在资源管理类提供对原始资源的访问

  • APIs 往往要求访问原始资源(raw resources)，所以每一个 RAII 类应该提供一个“取得其所管理之资源”的办法。
  • 对原始资源的访问可能经由显式转换或隐式转换。一般而言显式转换比较安全，但隐式转换比较方便。

条款 16：成对使用 new 和 delete 时要采取相同形式

  • 如果你在 new 表达式中使用 []，必须在相应的 delete 表达式中也使用 []。如果你在 new 表达式中不使用 []，一定不要在相应的 delete 表达式中使用 []。

条款 17：以独立语句将 new 得到的对象置入智能指针

  • 以独立的语句将 new 得到的对象存储于（置入）智能指针内。如果不这样做，一旦异常被抛出，有可能导致难以察觉的资源泄漏。

4. 设计与声明

条款 18：让接口容易被正确使用，不易被误用

  • 好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这一点。
  • “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
  • “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除使用者的资源管理责任。
  • tr1::shared_ptr 支持自定义删除器。这可防范 DLL 问题，可被用来自动解除互斥锁（mutexes，见条款 14）等等。

条款 19：设计 class 犹如设计 type

  • Class 的设计就是 type 的设计。在定义一个新 type 之前，请确定你已经考虑过本条款讨论过的所有主题。

条款 20：宁以 pass-by-reference-to-const 替换 pass-by-value

  • 尽量以 pass-by-reference-to-const 替换 pass-by-value。前者通常比较高效，并可避免切割问题(slicing problem)。
  • 以上规则并不适用于内置类型，以及 STL 的迭代器和函数对象。对它们而言，pass-by-value 往往比较适当。

条款 21：必须返回对象时，别妄想返回其引用

  • 绝不要返回指向栈中的局部对象的指针或引用，或返回指向堆中对象的引用，或返回指向静态局部变量对象的指针或引用。条款 4 已经为“在单线程环境中合理返回指向一个局部静态对象的引用”提供了一份设计实例。

条款 22：将成员变量声明为 private

  • 切记将成员变量声明为 private。这可赋予访问数据的一致性、可细微划分访问控制、允诺约束条件获得保证，并使得 class 开发更灵活。
  • protected 并不比 public 更具封装性。

条款 23：宁以 non-member、non-friend 替换 member 函数

  • 宁可拿 non-member 和 non-friend 函数替换 member 函数。这样做可以增加封装性、包装灵活性和机能扩充性。

条款 24：若所有参数皆需类型转换，请为此采用 non-member 函数

  • 如果你需要为某个函数的所有参数（包括被 this 指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个 non-member。

条款 25：考虑写出一个不抛异常的 swap 函数

  • 当 std::swap 对你的类型效率不高时，提供一个 swap 成员函数，并且定这个函数不抛出异常。
  • 如果你提供一个 member swap，也该提供一个 non-member swap 用来调用前者。对于 class（而非 template），也请特化 std::swap。
  • 调用 swap 时应针对 std::swap 使用 using 声明式，然后调用 swap 并且不带任何“命名空间资格修饰”。
  • 为“用户自定义类型”进行 std 模板全特化是好的，但千万不要尝试在 std 内加入某些对 std 而言全新的东西。

5. 实现

条款 26：尽可能延后变量定义式的出现时间

  • 尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。

条款 27：尽量少做类型转换

  • 如果可以，尽量避免类型转换，特别是在注重效率的代码中避免 dynamic_cast。如果有个设计需要类型转换，试着发展无需类型转换的替代设计。
  • 如果类型转换是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将类型转换放进他们自己的代码里。
  • 宁可使用 C++ 风格的新式类型转换，不要使用旧式类型转换。前者很容易辨识出来，而且不同的类型转换有不同的方法，非常清晰。

条款 28：避免返回 handles 指向对象内部成分

  • 避免返回 handles （包括引用、指针、迭代器）指向对象内部、遵守这个条款可增加封装性，帮助 const 成员函数的行为像个 const，并将发生悬空 handles 的可能性降至最低。

条款 29：为“异常安全”而努力是值得的

  • 异常安全函数(Exception-safe functions) 即使发生异常也不会泄漏资源或允许任何数据结构破坏。这样的函数区分三种可能的保证：基本型、强烈型、不抛异常型。
  • “强烈保证”往往能够以 copy-and-swap 实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义。
  • 函数提供的“异常安全保证”通常最高只等于其所调用的各个函数的“异常安全保证”中的最弱者。

条款 30：透彻了解 inline 的里里外外

  • 将大多数 inline 限制在小型、被频繁的调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化。
  • 不要只因为函数模板出现在头文件，就将它们声明为 inline。

条款 31：将文件间的编译依存关系降至最低

  • 支持“编译依存性最小化”的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是 Handle class 和 Interface class。
  • 程序库头文件应该以“完全且仅声明式”的形式存在。这种做法不论是否涉及模板都适用。

6. 继承与面向对象设计

条款 32：确定你的 public 继承塑模出 “is-a” 关系

条款 33：避免隐藏继承而来的名称

条款 34：区分接口继承和实现继承

条款 35：考虑 virtual 函数以外的其他选择

条款 36：绝不重新定义继承而来的 non-virtual 函数

条款 37：绝不重新定义继承而来的缺省参数值

条款 38：通过复合塑模出 “has-a” 或“根据某物实现出”

条款 39：明智而审慎地使用 private 继承

条款 40：明智而审慎地使用多重继承

7. 模板与泛型编程

条款 41：了解隐式接口和编译器多态

条款 42：了解 typename 的双重意义

条款 43：学习处理模板化基类内的名称

条款 44：将与参数无关的代码抽离 template

条款 45：运用成员函数模板接受所有兼容类型

条款 46：需要类型转换时为模板定义非成员函数

条款 47：请使用 traits classes 表现类型信息

条款 48：认识 template 元编程

8. 定制 new 和 delete

条款 49：了解 new-handler 的行为

条款 50：了解 new 和 delete 的合理替换实机

条款 51：编写 new 和 delete 时需固守常规

条款 52：写了 new 就也要写 delete

9. 杂项讨论

条款 53：不要轻忽编译器的警告

条款 54：让自己熟悉包括 TR1在内的标准程序库

TR1 已经在 C++ 11 中加入标准，命名空间直接就是 std::（以前是 std::tr1::）。

这里就不再赘述了，写此条款仅为了保持全书笔记完整性。

条款 55：让自己熟悉 Boost