Effective C++学习笔记（八） 实现（二）异常安全、inline

Effective C++学习笔记（八） 实现（二）

条款 29 为“异常安全”而努力是值得的
在异常抛出时，带有异常安全性的函数会：
（1）不泄露任何资源（2）不允许数据破坏
copy and swap 策略：修改对象数据的副本，然后在一个不抛出异常的函数中将修改后的数据和原件置换
函数提供的“异常安全性保证”通常只等于其所调用之各个函数的“异常安全保证”中的最弱者

条款 30 透彻了解inlining的里里外外
inline函数的好处在于动作像函数，调用他们又不需要承受函数调用所招致的额外开销，编译器 通常会优化inline函数。但是，inline的整体观念是将“对此函数的每一个调用”都以函数本体替换之，过度热衷于inlining会造成程序体积太大（对可用空间而言）。即使拥有虚拟内存，inline造成的代码膨胀亦会导致额外的换页行为，降低指令高速缓存装置的击中率。
inline只是对编译器的一个申请，不是强制的命令，这个申请可以隐喻的提出，也可以明确提出。隐喻提出的方式就是将函数定义在class式内，注意 ，是定义，还有定义在class中的friend函数。
大部分编译器会拒绝将太过复杂的函数inlining，而所有对virtual函数的调用也都会使inlining落空，因为virtual就意味着，要在运行时确定函数的本体，编译器通常不对“通过函数指针而进行的调用”实施inlining，构造函数和析构函数也不应该声明为inline。
（1）请将大所属inlining限制在小型，被频繁调用的函数身上。这可使日后调试过程和二进制升级更容易，也可是潜在的代码膨胀问题最小化，使程序的速度提升机会最大化
（2）不要因为function templates 出现在头文件，就将他们声明为inline。因为不是所有的template都需要声明为inline。

条款 31 将文件间的编译依存关系降到最低
（1）支持“编译依存性最小化”的一半构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段式handle class 和 interface class
（2）程序库头文件应该以“完全且仅有声明式”的形式存在。这种做法不论是否设计template都适用