effective C++读书笔记五 —— 实现

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

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

（2）

Widget w;                                 

for (int i = 0; i < n; ++i)          for (int i = 0; i < n; ++i)

{                             {

  w = f（i）;                        Widget w = f(i) ;       

  .....                           ......

}                             }

方法A比方法B更优。

25 条款27：尽量少做转型动作

（1）const_cast：常量性转除。

   dynamic_cast :“安全向下转型”，用来决定某对象是否归属继承体系中的某个类型

   reinterpret_cast：意图执行低级转型，例如将pointer to int 转型为一个int

   static_cast：强迫隐式转换，如int to double，non_const to const

尽量使用新式转型，原因：很容易识别。各转型动作的目标愈狭窄化，编译器愈可能诊断出错误的运用。

唯一使用旧式转型，调用一个explicit构造函数将一个对象传递给一个函数时。

       （2）任何一个类型转换，编译器编译出运行期间执行的码。

       （3）尽量避免转型，特别是在注重效率的代码中避免dynamic_casts，如果有个设计需要转型动作，试着发展无需转型的替代设计。比如derived class 调用base class中的。

       class SpecialWindow:public Window{

public:

  virtual void OnResize(){

     Window::onResize();       //调用window::onResize作用*this身上

  }

};

       （4）derived class对象身上执行derived class操作函数，但你的手上却只有一个“指向base”的pointer或reference。解决办法：将base class中对应的函数声明为虚函数，来替代转型。

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

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

（2）但并不意味你绝对不可以让成员函数返回handle，有时候必须这么做，例如operator[]就允许你strings和vectors的个别元素。而这些operator[]s就是返回references指向“容器内的数据”。

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

（1）异常安全的函数的条件：

l  不泄露任何资源

l  不允许数据败坏

（2）异常安全函数提供以下三个保证：

l  基本承诺。异常抛出，程序内任何事物仍然保持有效状态下。没有任何对象或数据结构因此而受到破坏。（可能出现任何合法的状态）

l  强烈保证。函数成功则完全成功，失败则返回调用之前的状态。（两种状态）

l  不抛掷保证。承诺不抛出异常。

（3）copy and swap原则：为你打算修改的对象做出一份副本，然后在那副本身上做出一切必要修改。若有任何修改动作抛出异常，原对象仍保持未改变的状态。待所有改变都成功后，再将修改过的那个副本和原对象在一个不抛出异常的操作中置换。

       “强烈保证”往往能够通过copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义。

（4）如何实现具备异常安全性：

l  “以对象管理资源”，那可阻止资源泄露。

l  然后挑选三个“异常安全保证”中的某一个实施于你所写的每一个函数身上。

28 条款30：透切了解inlining的里里外外

       （1）将大多数inlining限制在小型、频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化。

       （2）不要只因为function templates出现在头文件，就将它们声明为inline。

 

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

       （1）接口与实现的分离关键在于“声明的依存性”替换“定义的依存性”，那正是编译依存性最小化的本质。简单的设计策略：

l  如果使用object reference或object pointers能完成任务，就不要使用objects。

l  如果能够，尽量以class声明式替换class定义式。

l  为声明式和定义式提供不同的头文件。

（2）支持编译依存性最小化的一般构想是：相依于声明式，不要相依于定义式，基于此构想的两个手段是Handle classes和Interface classes.