Effective C++ Chapter5-实现

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;作前置声明。