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

• 宁可拿non-member non-friend函数替换member函数。这样做可以增加封装性、包裹弹性（packing flexibility）和机能扩充性。

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

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

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

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

5. 实现

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

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

条款27 尽量少做转型动作

• 如果可以，尽量避免转型，特别时在注重效率的代码中避免dynamic_casts。如果有个设计需要转型动作，试着发展无需转型的替代设计。
• 如果转型时必须的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将转型放进自己的代码内。
• 宁可使用C++-style（新式）转型，而不是用旧式转型。前者很容易辨识出来，而且也比较有着分门别类的执掌。

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

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

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

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

条款30 透彻了解inlining的里里外外

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

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

• 支持“编译依赖最小化”的一般构想是：依赖于声明式，不要依赖于定义式。基于此构想的两个手段时Handle classes和Interface classes。
• 程序库头文件应该以“完全且仅有声明式”（full and declaration-only forms）的形式存在。这种做法不论是否设计templates都适用。

6. 继承与面向对象

条款32 确定你的public继承塑模出Is-a关系

• “public继承”意味Is-a。适用于base class身上的每一件事情一定也适用于derived classes身上，因为每一个“derived class”对象也是一个base class对象。

条款33 避免遮掩继承而来的名称

• derived class内的名称会遮掩base class内的名称。在public继承下从来没有人希望如此。
• 为了让被遮掩的名称再见天日，可使用using声明式或转交函数（forwarding functions）。

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

• 接口继承和实现继承不同。在public继承之下，derived classes总是继承base class的接口。
• 纯虚（pure virtual）函数只具体指定接口继承。
• 非纯虚（impure virtual）函数具体指定接口继承及缺省实现继承。
• non-virtual函数具体指定接口继承预计强制性实现继承。

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

• virtual函数的替代方案包括NVI手法及Strategy设计模式的多种形式。NVI手法自身时一个特殊形式的Template Method设计模式。
• 将机能从成员函数移到class外部函数，带来的一个缺点时，非成员函数无法访问class的non-public成员。
• tr1::function（C++11已经移到std::function）对象的行为就像一般函数指针。这样的对象可接纳“与给定之目标签名式（target signature）兼容”的所有可调用物（callable entities）。

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

• 绝对不要重新定义继承而来的non-virtual函数。

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

• 绝对不要重新定义一个继承而来的缺省参数值，因为缺省参数值是静态绑定，而virtual函数——你唯一应该覆写的定西——确是动态绑定。

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

• 复合（composition）的意义和public继承完全不同。
• 在应用域（application domain），复合意味着has-a（有一个），在实现域（implementation domain），复合意味着is-implemented-in-terms-of（根据某物实现出）。

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

• Private继承意味着is-implemented-in-terms-of（根据某物实现出）。它通常比复合（composition）的级别低。但是当derived class 需要访问protected base class的成员，或需要重新定义继承而来的virtual函数时，这么设计时合理的。
• 和复合（composition）不同，private继承可以造成empty base最优化。这对致力于“对象尺寸最小化”的程序库开发者而言，可能很重要。

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

• 多重继承比单一继承复杂。它可能导致新的歧义性，以及对virtual继承的需要。
• virtual继承会增加大小、速度、初始化（及赋值）复杂度等成本。如果virtual base classes不带任何数据，将时最具有实用价值的情况。
• 多重继承的确有正当用途。其中一个情节涉及“public继承某个interface class”和“private继承某个协助实现的class”的两相组合。

7. 模板与泛型编程