***************************************转载请注明出处：http://blog.csdn.net/lttree********************************************
五、Implementations
Rule 30：Understand the ins and outs of inlining
规则 30：透彻了解inlining的里里外外
1.inline 的优缺点
> 优点
——看起来像函数
——动作像函数
——比宏好很多
——可以调用它们又不需要蒙受函数调用所招致的额外开销
——编译器最优化机制通常被设计用来浓缩那些“不含函数调用”的代码，所以当你inline某个函数，或许编译器就因此——有能力对它（函数本体）执行预警相关最优化。大部分的编译器不会对一个“outlined函数调用”动作执行如此之最优化
> 缺点
——可能增加目标码（object code）的大小
——inline造成的代码膨胀会导致额外的换页行为，降低指令告诉缓存装置的击中率，以及伴随这些而来的效率损失
2.观点
记住——
inline只是对编译器的一个申请，不是强制命令。
> 声明
这项申请可以隐喻的提出，也可以明确的提出。
隐喻方式是将函数定义于class定义式内：
class Person {
public:
...
// 一个隐喻的inline申请：age被定义于class定义式内
int age() const { return theAge; }
...
private:
int theAge;
};
在条款46中会提到，friend函数也可以定义于class内，所以它们也是被隐喻声明为 inline
明确声明做法则是在其定义式前加上关键字inline。例如标准的max template（来自<algorithm>）往往这样实现：
template<typename T>
inline const T& std::max(const T& a,const T& b)
{ return a<b?b:a; }
> inline and template
inline函数 和 template 两者通常都被定义在头文件内，这使得某些程序员认为 function template 一定必须是inline，有必要好好看一下这两者:
——Inline函数通常一定被置于头文件内，因为大多数建置环境在编译过程中进行inlining，而为了将一个“函数调用”替换为“被调用函数的本体”，编译器必须知道那个函数长什么样子。某些建置环境可以再连接期完成inlining，少量建置环境如 基于.NET CLI；公共语的托管环境竟可在运行期完成inlining。
inlining在大多数C++程序中是编译器行为。
——Template 通常也被置于头文件内，因为它一旦被使用，编译器为了将它具现化，需要知道它长什么样子。
Template的具现化与inlining无关。如果你写的template没有理由要求它所具现的每一个函数都是inlined，就应该避免将这个template声明为inline。
因为inline需要成本，在缺点中提到过代码膨胀，但还存在其他的成本。
3.于编译器角度看 inline
一个表面上看似inline的函数是否真是inline，取决于你的建置环境，主要取决于编译器。
幸运的一件事——大多数编译器提供了一个诊断级别：如果它们无法将你要求的函数inline化，会给一个warning
> 大部分编译器拒绝将太过复杂（含有循环或递归）的函数inlining，而所有对virtual函数的调用也都会使inline落空。
因为virtual意味着“等待，直到运行期才确定调用哪个函数”，而inline意味着“执行前，先将调用动作替换为被调用函数的本体”。编译器根本不知道你调用哪个函数，如何替换？
> 有时候虽然编译器有意愿inlining某个函数，还是可能为该函数生成一个函数本体。
比如，如果程序要取某个inline函数的地址，编译器通常必须为此函数生成一个 outlined 函数本体。毕竟编译器无法让一个指针指向并不存在的函数。
而且，编译器通常不对“通过函数指针而进行的调用”实施inlining，这意味对inline函数的调用可能被inlined，取决于该调用的实施方式：
// 假设编译器有意愿inline“对f的调用”
inline void f() { ... }
// pf 指向 f
void (*pf)() = f;
...
// 这个调用将被inlined，因为他是一个正常调用
f();
// 这个调用或许不被inlined，因为它通过函数指针达成
pf();
实际上构造函数和析构函数往往是inlining的糟糕候选人——虽然漫不经心的情况下你不会这么认为。
class Base {
public:
...
private:
std::string bm1,bm2;
};
class Derived : public Base {
public:
Derived() { }
...
private:
std::string dm1,dm2,dm3;
};
这个构造函数看起来是inlining的候选人，因为它根本不包含任何代码。
但 事实并不如此 ！
C++对于“对象被创建和被销毁时发生什么事”做了各式各样的保证。
当你使用 new，动态创建的对象被其构造函数自动初始化；当你使用delete，对应的析构函数会被调用。
当你创建一个对象，其每一个base class以及每一个成员变量都会被自动构造；当你销毁一个对象，反向程序的析构行为亦会自动发生。
如果有个异常在对象构造期间被抛出，该对象已构造好的那一部分会被自动销毁。
在这些情况中C++描述了什么一定会发生，但没有说如何发生。
“事情如何发生”是编译器实现者的权责，它们不可能凭空发生，在我们的程序中一定有某些代码让那些事情发生。
这些代码有时候放在你的构造函数和析构函数内，所以，我们可以想象到，编译器为上面那个看起来是空的Derived构造函数所产生的代码，应该是这样的：
Derived::Derived()
{
// 初始化 Base成分
Base::Base();
// 试图构造dm1
try { dm1.std::string::string(); }
catch(...) {
// 如果抛出异常 销毁 base class成分，并传播该异常
Base::~Base();
throw;
}
// 试图构造dm2
try { dm2.std::string::string(); }
catch(...) {
// 如果抛出异常，销毁dm1 base class 成分，并传播异常
dm1.std::string::~string();
Base::~Base();
throw;
}
// 试图构造dm3
try { dm3.std::string::string(); }
catch(...) {
// 如果抛出异常，销毁dm2，dm1，base class成分，并传播该异常
dm2.std::string::~string();
dm1.std::string::~string();
Base::~Base();
throw;
}
}
这段代码并不能代表编译器真正能制造出来的代码，因为真正的编译器会以更精致复杂的做法来处理异常。
虽然如此，这也已经准确反映Derived的空白构造函数所必须提供的行为。
不论编译器在其内所做的异常处理多么精致复杂，Derived的构造函数至少一定会陆续调用其成员变量和base class两者的构造函数，而那些调用（它们自身也可能被inlined）会影响编译器是否对此空白函数inlining。
相同理由也适用于Base构造函数，所以如果它被inlined，所有替换“Base构造函数调用”而插入的代码也都会被插入到“Derived构造函数调用”内（因为Derived构造函数调用了Base构造函数）。
所以，程序库设计者必须评估“将函数声明为inline”的冲击；inline函数无法随着程序库的升级而升级。
若从纯粹实用的观点出发，有一个事实比其他因素更重要：大部分调试器面对inline函数都束手无策。
毕竟你没办法在一个并不存在的函数内设立断点。
4.总结
在决定哪些函数盖被声明为inline而哪些函数不该时，掌握一个合乎逻辑的策略
> 一开始先不要将任何函数声明为inline，或至少将inlining施行范围局限在那些”一定成为inline”或“十分平淡无奇”的函数身上。
> 慎重使用inline便是对日后使用调试器带来帮助，不过这么一来也等于把自己推向手工最优化的道路。
> 不要忘记 80-20 经验法则：平均一个程序往往将80%的执行时间花在20%的代码上头。所以，找出可以有效增进程序整体效率的20%代码，然后将它inline或接近所能地将它瘦身。BUT，首先你要选对目标！
☆ 请记住 ☆
? 将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可潜在的代码膨胀问题最小化，使程序的速度提升机会最大化。
? 不要只因为 function templates 出现在头文件，就将它们声明为inline。
***************************************转载请注明出处：http://blog.csdn.net/lttree********************************************