实现
- 条款 26 - 尽可能延后变量定义式的出现时间
- 尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。
- 条款 27 - 尽量少做转型动作
- 如果可以，尽量避免转型，特别是在注重效率的代码中避免 dynamic_casts。如果有个设计需要转型动作，试着发展无需转型的替代设计。
- 如果转型是必要的，试着将它隐藏与某个函数背后。客户随后可以使用该函数，而不需要将转型写他们自己的代码中。
- 宁可使用 c++ style （新式）转型，不要使用旧式转型。前者可很容易辨识出来，而且也比较有着分门别类的职掌。
C++ 转型说明：
- const_cast 通常用来将对象的常量性转除。它也是唯一有此能力的 c++ style 转型操作符。
- dynamic_cast 主要用来执行安全向下转型，也就是用来决定某对象是否归属继承体系中的某个类型。它是唯一无法由旧式语法执行的动作，也是唯一可能耗费重大运行成本的转型动作。
- reinterpret_cast 意图执行低级转型，实际动作取于编译器，这意味着其不可移植。
- static_cast 用来强迫隐式转换，例如将 non-const 对象转为 const 对象，或者将 int 转型为 double 。它也可以用来执行上述多种转换的反向转换，例如将 void* 转换为 typed 指针，将 pointer-to-base 转型为 pointer-to-derived。但它无法将 const 转换为 non-const。
- 条款 28 - 避免返回 handles 指向对象内部成分
- 避免返回 handles (包括 pointer、references、iterator) 指向对象内部。遵守这个条款可增加封装性，帮助 const 成员函数像个 const，并将发生 “虚吊号牌” 的可能性降至最低。
- 条款 29 - 为异常安全而努力是值得的
- 异常安全函数即使发生异常也绝不会泄漏资源或者允许任何数据结构破坏。这样的函数区分为三种可能的保证：基本型、强烈型、不抛异常型。
- "强烈保证" 往往能够以 copy-and-swap 实现出来，但 “强烈保证” 并非对所有函数都可实现或具备现实意义。
- 函数提供的 “异常安全保证” 通常最高只等于其所调用之各个函数的 “异常安全保证” 中的最弱者。
- 条款 30 - 透彻了解 inlining 的里里外外
- 将大多数 inlining 限制在小型、被频繁调用的函数上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化。
- 不要只因为 function templates 出现在头文件，就将它声明为 inline。
- 条款 31 - 将文件间的编译依存关系降至最低
- 支持 “编译依存性最小化” 的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是 Handle classes 和 Interface classes。
- 程序库头文件应该以 “完全仅有声明式” 的形式存在。这种做法无论是否涉及 templates 都适用。
