26、尽可能延后变量定义式的出现时间
- 条款4曾经解释为什么“通过defailt构造函数构造出一个对象然后对它赋值”比“直接在构造函数时赋初值”效率差。
27、尽量少做转型动作
- 旧式转换 C风格：（T）expression
T（espression）//函数风格 - C++提供四种新式转型（c++style casts）:
const_cast < T >( expression )
dynamic_cast < T >( expression )
reinterpret_cast < T >( expression )
static_cast < T >( expression ) - const_cast 通常将对象的常量属性转除（cast away the constness），他也是唯一由此能力的c++style转型操作符。
- dynamic_cast主要用来执行“安全向下转型”（safe downcasting），也就是用来决定某对象是否归属继承体系中的某个转型。它是唯一无法用旧式语法执行的动作，也是唯一可能耗费重大运行成本的转型动作。
- reinterpret_cast意图执行低级转型，实际动作（以及结果）可能取决于编译器，这也就表示它不可移植。例如将一个pointer_to_int 转换成一个int。这一类转换在低级代码以外很少见，本书只使用一次，那就是讨论如何针对一个原始内存写处一个调试用的分配器（debugging allocator）时，见50。
-
static_cast用来强迫隐式转换（implicit conversions）,例如将non-const对象转换为const对象（像条款3所为），或将int转换为double等等
，他也可以执行许多类型的反转换，例如将void* 转换为type指针，将pointer_to_base转换为pointer_to_derived。但是它无法将const转为non-const---这个只有const_cast才能办到。 - 如果可以，尽量避免转型，特别是在注重效率的代码中避免 dynamic_cast。
- 如果转型是必要的，是这将它隐藏于某个函数背后。客户可以随时调用该函数，而不需将转换放进他们的代码中。
28、
29、为异常安全而努力是值得的 Strive for exception-safe code
- “异常安全"有俩个条件：
1、不泄露任何资源（解决此问题的方法是13以对象管理资源）
2、不允许数据败坏 - 异常安全函数（exception-safe functions）提供以下三种保证之一：
1、基本承诺 如果异常被抛出，程序的任何事物仍然保持在有效状态下。
2、强烈保证 如果异常被抛出，程序状态不改变。即调用这样的函数，若成功，则完全成功；若失败，就要回到函数调用之前的状态。
3、不抛掷保证 即承偌绝不抛出异常 - 策略“copy and swap” 会保证 2强烈保证
- 请记住：
- 异常安全函数 即使发生异常也不会写罗资源或允许任何数据结构被破坏。这样的函数区分为三种可能的保证：基本型、强烈型、不抛掷异常型。
- “强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可以实现或具备现实意义。
- 函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。
30、透彻了解inlining的里里外外
-
inline函数背后的整体观念是，“将对此函数的每一个调用”都以函数本体替换之。大多数情况下为编译期行为。
inline隐喻申请.png
inline函数的明确声明.png
- 大多数编译器拒绝对太过于复杂的函数（例如带有递归或者循环）inlining， 而所有的virtual函数的调用（除非是最平淡无奇的）也都会被inlining落空。所以这取决于你的建制环境，主要取决于编译器。若不成功，会发出警告（见53）。
- 编译器通常不对“通过函数指针而进行的调用”实施inlining。
函数指针.png
- 大多数inline函数限制在
31、将文件编译依存关系的降到最低
- C++编译器必须在编译期间知道对象的大小。
- C++并没有把“将接口从实现中分离”这件事做的很好。Class的定义式不只是详细叙述了class接口，还包括十足的实现细目。
- 标准程序库组件不应该被前置声明，仅仅应该使用简单的#include来实现，如使用#incldue<string>而不是 class string;作前置声明。
