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

0.概述

将大多数inlining 限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级( binary upgradability）更容易，也可使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化。
不要只因为function templates 出现在头文件，就将它们声明为inline。

1. Inline的好处

它们看起来像函数，动作像函数，比宏好得多（见条款2)，可以调用它们又不需蒙受函数调用所招致的额外开销。inline之后编译器还可以对其执行语境相关最优化。

2.inline的坏处

对函数的每次调用都以函数本体替换，除非本体码比调用码少，否则会增加目标码大小，造成代码膨胀，这会导致额外的换页行为，降低指令高速缓存装置的击中率，引起效率损失。

inline函数无法随程序库的升级而升级：假设f是一个inline函数，一旦改变了f，所有用到f的客户端都需要重新编译（如果是非inline客户端只需要重新连接就行）（如果程序库采用动态连接，这种改变甚至会不知不觉被程序吸纳）

调试器无法对inline函数进行调试

3. inline的申请

inline只是对编译器的一个申请，不是强制命令，这个申请可以隐喻提出，也可以明确提出。

3.1 隐喻提出

将函数定义域class定义式中，通常是成员函数或友元函数

class Person {
    public:
        ...
        int age() const { return theAge; } // an implicit inline request: age is
        ... // defined in a class definition
    private:
        int theAge;
};

3.2 明确提出

在定义式前加关键字inline，以某函数模板为例：

template // an explicit inline
inline const T& std::max(const T& a, const T& b) // request: std::max is
{ return a < b ? b : a; } // preceded by “inline”

4. Inline通常被定义于头文件中

Inline和template通常都被定义于头文件中，但这并不代表函数模板一定是inline。

为啥Inline通常被置于头文件中？

因为大多数建置环境(build environments)在编译过程中进行inlining，而为了将一个“函数调用”替换为本体，编译器必须知道那个函数长什么样子。

某些建置环境可以在连接期完成inlining，

少量建置环境如基于.NET CLI (Common Language Infrastructure:公共语言基础设施）的托管环境(managed environments）竟可在运行期完成inlining。

然而这样的环境毕竟是例外，不是通例。Inlining 在大多数C++程序中是编译期行为。

5.拒绝inline的情况

一个表面上看似inline的函数是否真是inline，取决于建置环境，主要取决于编译器。

好在大多数编译器如果无法将你要求的函数inline化，会给你一个警告信息（见条款53)。

5.1 太过复杂的函数

如带有循环或递归

5.2 虚函数

virtual意味“等待，直到运行期才确定调用哪个函数”，而 inline意味“执行前，先将调用动作替换为被调用函数的本体”。编译器不知道该调用哪个函数，所以它们拒绝将函数本体inlining.

5.3 取inline函数的地址或通过指针进行调用

如果程序要取某个inline函数的地址，编译器通常必须为此函数生成一个outlined函数本体。毕竟编译器没有能力提出一个指针指向并不存在的函数。

此外，编译器通常不对“通过函数指针而进行的调用”实施inlining,这意味对inline函数的调用有可能被inlined，也可能不被inlined，取决于该调用的实施方式

inline void f() {...} // 假设编译器想inline对f的调用
void (*pf )() = f; // pf指向f
...
f(); // 被inline
pf(); // 可能不被inline

5.4 构造函数或析构函数

考虑一个派生类的空构造函数

class Base {
    public:
    ...
    private:
    std::string bm1, bm2; // base members 1 and 2
};
class Derived: public Base {
    public:
    Derived() {} // Derived’s ctor is empty — or is it?
    ...
    private:
    std::string dm1, dm2, dm3; // derived members 1–3
};

看起来可以使用inline鸭，因为不含任何代码，但实际上编译器会为它产生代码（本例中不包含异常处理部分）：

Derived::Derived() // conceptual implementation of
{ // “empty” Derived ctor
    Base::Base(); // 初始化基类成分
    try { dm1.std::string::string(); } // try to construct dm1
    catch (...) { // if it throws,
    Base::~Base(); // destroy base class part and
    throw; // propagate the exception
    }
    try { dm2.std::string::string(); } // 试图构造dm2
    catch(...) { // if it throws,
    dm1.std::string::~string(); // destroy dm1,
    Base::~Base(); // destroy base class part, and
    throw; // propagate the exception
    }
    try { dm3.std::string::string(); } // 试图构造dm3
    catch(...) { // if it throws,
    dm2.std::string::~string(); // destroy dm2,
    dm1.std::string::~string(); // destroy dm1,
    Base::~Base(); // destroy base class part, and
    throw; // propagate the exception
    }
}

上述代码中的所有调用都会影响编译器是否对此构造函数inlining