[翻译] Effective C++, 3rd Edition, Item 30: 了解 inlining（内联化）的来龙去脉（下）

（点击此处，接上篇）

有时候，即使编译器完全心甘情愿地 inline 一个函数，它们还是会为这个 inline function 生成函数本体。例如，如果你的程序要持有一个 inline function 的地址，编译器通常必然为它生成一个 outlined 函数本体。它们怎么能拿得出一个指向根本不存在的函数的指针呢？再加上编译器一般不会对通过函数指针的调用进行 inlining（内联化）的事实，这就意味着，对一个 inline function 的调用可能被也可能不被内联，这要依赖于这个调用是如何做成的：

inline void f() {...}      // assume compilers are willing to inline calls to f

void (*pf)() = f;          // pf points to f

...

f();                       // this call will be inlined, because it's a "normal" call
pf();                      // this call probably won't be, because it's through
                           // a function pointer

甚至在你从来没有使用函数指针的时候，un-inlined inline functions（未被内联的内联函数）的幽灵也会神秘地拜访你，因为程序员并不一定是函数指针的唯一需求者。有时候编译器会生成 constructors（构造函数）和 destructors（析构函数）的 out-of-line 拷贝，以便它们能得到指向这些函数的指针，在对数组中的 objects 进行构造和析构的过程中使用。

事实上，对于 inlining（内联化）来说，constructors（构造函数）和 destructors（析构函数）经常是一个比在不经意的检查中所能显示出来的更加糟糕的候选者。例如，考虑下面这个 class Derived 的 constructor（构造函数）：

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
};

这个 constructor（构造函数）看上去像一个 inlining（内联化）的极好的候选者，因为它不包含代码。但是视觉会被欺骗。

C++ 为 objects 被创建和被销毁时所发生的事情做出了各种保证。例如，当你使用 new 时，你的被动态创建的 objects 会被它们的 constructors（构造函数）自动初始化，而当你使用 delete 时，则相应的 destructors（析构函数）被调用。当你创建一个 object 时，这个 object 的每一个 base class（基类）和每一个 data member（数据成员）都会被自动构造，而当一个 object 被销毁时，则自动发生关于析构的反向过程。如果在一个 object 的构造期间有一个异常被抛出，这个 object 已经完全构造好的任何构件都被自动销毁。所有这些环节，C++ 只说什么必须发生，但没有说如何发生。那是编译器实现者的事，但显然这些事情不会自己发生。在你的程序中必须有一些代码使这些事发生，而这些代码——由编译器写出的代码和在编译期间插入你的程序的代码——必须位于某处。有时它们最终就位于 constructors（构造函数）和 destructors（析构函数）中，所以我们可以设想实现为上面那个声称为空的 Derived constructor 生成相当于下面这样的代码：

Derived::Derived()                       // conceptual implementation of
{                                        // "empty" Derived ctor

 Base::Base();                           // initialize Base part

 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(); }      // try to construct 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(); }      // construct 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
 }
}

这些代码相对于真正的编译器所生成的代码不具有代表性，因为真正的编译器会用更复杂的方法处理异常。尽管如此，它还是准确地反映了 Derived 的 "empty" constructor （“空”构造函数）必须提供的行为。不论一个编译器的异常实现多么复杂，Derived 的 constructor（构造函数）至少必须调用它的 data members（数据成员）和 base class（基类）的 constructors（构造函数），而这些调用（它们自己也可能是被内联的）会影响它对于 inlining（内联化）的吸引力。

同样的原因也适用于 Base constructor，所以如果它是被内联的，插入它的全部代码也要插入 Derived constructor（通过 Derived constructor 对 Base constructor 的调用）。而且如果 string 的构造函数碰巧也是被内联的，Derived constructor 中将增加那个函数的代码的五个拷贝，分别对应于一个 Derived object 中的五个 strings（两个继承的加上三个它自己声明的）。也许在现在，为什么是否内联 Derived 的 constructor 不是一个不经大脑的决定就很清楚了。类似的考虑也适用于 Derived 的 destructor，用同样的或者不同的方法，必须保证所有被 Derived 的 constructor 初始化的 objects 被完全销毁。

库设计者必须评估声明函数为 inline 的影响，因为为一个库中的可见的 inline functions 提供二进制升级是不可能的。换句话说，如果 f 是一个库中的一个 inline functions，库的客户将函数 f 的本体编译到他们的应用程序中。如果一个库的实现者后来决定修改 f，所有使用了 f 的客户都必须重新编译。这常常会令人厌烦。在另一方面，如果 f 是一个 non-inline function，对 f 的改变只需要客户重新链接。这与重新编译相比显然减轻了很大的负担，而且，如果库包含的函数是被动态链接的，这可能就是一种对于用户来说完全透明的方法。

为了程序开发的目标，在头脑中牢记这些需要考虑的事项是很重要的，但是从编码期间的实践观点来看，占有支配地位的事实是：大多数调试器会与 inline functions 发生冲突。这应该不是什么重大的新发现。你怎么能在一个不在那里的函数中设置一个断点呢？虽然一些构建环境设法支持 inline functions 的调试，多数环境还是简单地为调试构建取消了 inlining（内联化）。

这就导出了一个用于决定哪些函数应该被声明为 inline，哪些不应该的合乎逻辑的策略。最初，不要 inline 任何东西，或者至少要将你的 inlining（内联化）的范围限制在那些必须 inline 的（参见 Item 46）和那些实在微不足道的（就像第 135 页上的 Person::age）函数上。通过慎重地使用 inlines，你可以使调试器的使用变得容易，但是你也将 inlining（内联化）放在了它应在的地位：作为一种手动的优化。不要忘记由经验确定的 80-20 规则，它宣称一个典型的程序用 80% 的时间执行 20% 的代码。这是一个重要的规则，因为它提醒你作为一个软件开发者的目标是识别出能提升你的程序的整体性能的 20% 的代码。你可以 inline 或者用其他方式无限期地调节你的函数，但除非你将精力集中在正确的函数上，否则就是白白浪费精力。

Things to Remember

• 将大部分 inlining（内联化）限制在小的，频繁调用的函数上。这使得程序调试和二进制升级更加容易，最小化潜在的代码膨胀，并最大化提高程序速度的可能性。

• 不要仅仅因为 function templates（函数模板）出现在头文件中，就将它声明为 inline。