Effective C++学习笔记（5）

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

• 1. 尽可能延后变量定义式的出现时间：有时调用的函数中可能会发生异常并向上抛出或者提前返回。如果该函数把函数中将所有可能用到的变量均在最前面进行声明/初始化，那么异常抛出/提前返回后，处于异常/返回代码后面的第一次使用部分变量的代码将会执行不到。此时，函数需要为一些未曾使用到变量进行构造和析构，降低了效率。同时，定义和使用变量不在彼此附近的位置，影响代码阅读性。
• 2. 定义循环中的变量有两种情况：最终选择A or B要看对象w的“构造+析构”成本是否小于“赋值成本”。
     

条款27. 尽量少做转型动作

• 1. 如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_cast。如果有个设计需要转型动作，试着发展无需转型的替代设计
• 2. 如果转型是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将转型放进他们的代码里。
• 3. 宁可使用C+±style（新式）转型，不要使用旧式转型。前者很容易识别出来，而且也比较有着分门别类的职掌。
• 4. 转型需要注意的几点情况：
     （1）一个base class 指针指问一个derved class对象，但有时候上述的两个指针值并不相同。这种情况下会有个偏移量（offset），在运行期被施行于Derived * 指针身上，用以取得正确的 Base *指针值。
     （2）应避免对指针类型转型后再进行算术操作，这种行为无定义。
     （3）对于多态情况中基类与派生类指针使用，当调用函数为虚函数时，到底调用的是基类对象的函数还是派生类对象的函数，与指向对象的虚函数指针有关。
• 5. 新式转型内容：
     （1）const_cast通常被用来将对象的常量性转除。它也是唯一有此能力的C+±style转型操作符。
     （2）dynamic_cast主要用来执行“安全向下转型”，也就是用来决定某对象是否归属继承体系中的某个类型。它是唯一无法由旧式语法执行的动作，也是唯一可能耗费重大运行成本的转型动作。
     （3）reinterpret_cast意图执行低级转型，例如将一个pointer to int转型为一个int。实际动作可能取决于编译器，这也就表示它不可移植。
     （4）static_cast用来强迫隐式转换，例如将non-const对象转为const对象，或将int转为double等等。它也可以用来执行上述多种转换的反向转换，例如将void*指针转为typed指针，将pointer-to-base转为pointer-to-derived。但它无法将const转为non-const一这个只有const_cast才办得到。

条款28. 避免返回handles指向对象内部部分

• 1. 避免返回handles（包括指针，引用，迭代器）指向对象内部部分，这样可以增加分装性。
     （1）成员变量的封装性最多只等于“返回其handles”的函数的访问级别。函数调用者可以轻松修改对象数据。
     （2）如果const成员函数传出去一个本类对象handles，违背了const成员函数应有的不修改对象数据的性质。
     （3）绝不应该使得一个成员函数返回一个指向“访问级别较低”的成员函数指针（少见）。
     解决方法：可以在返回值上加上const属性，使得调用者只许读，不许改
     （4）空悬的号码牌（dangling handles）：handles指向东西不存在。下例中函数返回一个temp临时对象，调用语句结束后，temp会被析构。
     

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

• 1. 异常安全函数即使发生异常也不会泄漏资源或允许任何数据结构败坏。这样的函数区分为三种可能的保证:基本型、强烈型、不抛异常型。
     （1）基本型：如果异常被抛出，程序内的任何事物仍然保持在有效状态下。没有任何对象或数据结构会因此而败坏，所有对象都处于一种内部前后一致的状态。
     （2）强烈型：如果异常被抛出，程序状态不改变。调用这样的函数需有这样的认知:如果函数成功，就是完全成功，如果函数失败，程序会恢复到“调用函数之前”的状态。
     （3）不抛异常型：承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能。作用于内置类型（例如ints，指针等等）身上的所有操作都提供nothrow保证。这是异常安全码中一个必不可少的关键基础材料。
• 2. “强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义（下述第3点）。
     原因：为你打算修改的对象（原件）做出一份副本，然后在那副本身上做一切必要修改。若有任何修改动作抛出异常，原对象仍保持未改变状态。待所有改变都成功后，再将修改过的那个副本和原对象在一个不抛出异常的操作中置换(swap)。
• 3. 函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。如果系统（函数）内有一个函数不具备异常安全性，那么整个系统（函数）就不具备异常安全性。

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

• 1. 将大多数inlining 限制在小型、被频繁调用的函数身上。这可使日后的调试过程和进制升级（binary upgradability）更容易，也可使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化。
• 2. 不要只因为function templates 出现在头文件，就将它们声明为inline。
     注意：
     （1）inline只是对编译器的一个申请，不是强制命令.隐喻内联如下；
     

（2）inline函数和函数模板通常一定被置于头文件内，因为在编译过程中，需要将函数调用替换成内联函数体/实例化函数模板，编译器需要知道它们长什么样；
（3）编译器通常不对“通过函数指针而进行的函数调用”实施内联，因为编译器没有能力为内联函数生成一个outlined函数本体，无法取得函数地址；

（4）构造函数和析构函数往往是inlining的糟糕候选人，因为两者会自动调用父类的构造和析构。

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

• 1. 支持“编译依存性最小化”的一-般构想是:相依于声明式，不要相依于定义式。基于此构想的两个手段是Handle classes和 Interface classes。
     （1）Handle classes：也常被称为pimpl idiom（pointer 同implementation），建立一个管理类，其中有一个智能指针指向被管理类对象（底层操作对象），将客户与被管理类对象分离。当被管理类发生迭代修改后，客户端无需重新编译自己的代码，只需拷入新实现类的编译好的文件。
     （2）Interface classes：制作一个抽象基类作为接口类，虚函数作为函数接口，其余实现类继承该接口类。客户端只需使用接口类指针（基类指针）指向继承类对象即可实现多态功能。只要接口函数不变，客户端就无需重新编译。
• 2. 程序库头文件应该以“完全且仅有声明式”(full and declaration-only forms）的形式存在。这种做法不论是否涉及templates 都适用。实现接口与实现分离。