《Effective C++》实现 章节

Item26：尽可能延后变量定义式的出现时间

---

Item27：尽量少做转型动作

关于这一点，专门开了一个新的总结：

http://blog.csdn.net/m0_37316917/article/details/70037711

---

Item28：避免返回handles指向对象的内部成分

总结：

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

---

Item29：为“异常安全”而努力是值得的

当异常被抛出时：

• 不泄露任何资源。

• 不允许数据破坏。

  异常安全函数提供以下三个保证之一：

  • 基本承诺：如果异常抛出，程序内的任何事物依然保持在有效状态下。没有任何对象或数据结构会因此破坏。所有对象都处于一种内部前后一致的状态。然而程序的现实状态可能无法预料。举个例子，我们可以撰写changeBackground使得一旦有异常被抛出时，PrettyMenu对象可以继续拥有原背景图像，或者令它拥有一个默认的背景图像，但客户无法预期是哪一种情况，如果想知道，恐怕要调用某个成员函数的时候才能知道了。
  • 强烈保证：如果异常抛出，程序状态不改变。调用这样的函数需要有这样的认识：如果函数成功，就是完全成功，如果函数失败，程序就回到调用之前的状态。
  • 不抛掷（nothrow）保证：承诺绝对不抛出异常，因为它们总是能够完全它们原先承诺的功能。作用于内置类型（int等）身上所有的操作都提供nothrow保证。
    
    总结：
• 异常安全函数即使发生异常也不泄露资源或允许任何数据破坏。这样的函数区分为三种可能：基本型，强烈型，不抛异常型。
• “强烈保证型”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义。
• 函数提供的“异常安全保证”通常最高只等于其所调用的各个函数的“异常安全保证”中的最弱者。

---

Item30：透彻了解inline的里里外外

inline函数通常一定被置于头文件内，因为大多数环境在编译过程中进行inling，而为了将一个“函数调用”替换为“被调用的函数的本体”，编译器需要知道那个函数长什么样子，inling在大多数C++程序中是编译期行为。
大部分编译器拒绝太过复杂（例如带有循环或递归）的函数inling，而对所有的virtual函数调用（除非是最平淡无奇的）也都会使得inling落空。这应该不会令你惊讶，因为virtual意味着“等待，直到运行期才确定调用哪个函数”，而inling意味着“执行前先将调用的动作做替换为被调用函数的本体”。
inling函数无法随着程序的升级而升级，换句话说，如果f是程序库中的一个inling函数，客户将f函数本体编进程序中，一旦程序库设计者决定改变f，所有用到f的客户端程序都必须重新编译，这将是很大的负担，而如果f是个non-inline函数，一旦它有任何修改，客户端都只需要重新链接就好，远比重新编译的负担要小的多，如果程序库采用动态连接，升级版函数升值可以不知不觉地被应用进程吸纳。

总结：

• 将大多数inling限制在小型、被频繁调用的函数上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀的问题最小化，使程序的运行速度最大化。
• 不要只因为template function出现在了头文件，就将它声明为inline。

---

Item31：将文件间的编译依存关系降至最低

①如果使用object references或者object pointers可以完成任务，就不要使用objects，你可以只靠一个类型声明式就定义出指向该类型的references和pointers，但如果定义某类型的objects，就需要用到该类型的定义式。

②如果能够，尽量以class声明式替换class定义式，注意：当你声明一个函数而它用到某个class的时候，你并不需要该class的定义式，纵使函数以by value的方式传递该类型的参数（或者返回值）。

class　Date;//class声明式
Date today;//没问题，这里并不需要Date的定义式
void clearAppoinment(Date d);//这里也不需要

但是在函数被调用之前，Date的定义式一定得被曝光才行

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