内联函数的effective C++解释

曾经终败给现在 2022-08-18 14:23 133阅读 0赞

Effective C++：  
条款33: 明智地使用内联  
内联函数——多妙的主意啊！它们看起来象函数，运作起来象函数，比宏(macro)要好得多（参见条款1），使用时还不需要承担函数调用的开销。你还能对它们要求更多吗？

然而，你从它们得到的确实比你想象的要多，因为避免函数调用的开销仅仅是问题的一个方面。为了处理那些没有函数调用的代码，编译器优化程序本身进行了专门的设计。所以当内联一个函数时，编译器可以对函数体执行特定环境下的优化工作。这样的优化对”正常”的函数调用是不可能的。

我们还是不要扯得太远。程序世界和现实生活一样，从来就没有免费的午餐，内联函数也不例外。内联函数的基本思想在于将每个函数调用以它的代码体来替换。用不着统计专家出面就可以看出，这种做法很可能会增加整个目标代码的体积。在一台内存有限的计算机里，过分地使用内联所产生的程序会因为有太大的体积而导致可用空间不够。即使可以使用虚拟内存，内联造成的代码膨胀也可能会导致不合理的页面调度行为（系统颠簸），这将使你的程序运行慢得象在爬。（当然，它也为磁盘控制器提供了一个极好的锻炼方式:)）过多的内联还会降低指令高速缓存的命中率，从而使取指令的速度降低，因为从主存取指令当然比从缓存要慢。

另一方面，如果内联函数体非常短，编译器为这个函数体生成的代码就会真的比为函数调用生成的代码要小许多。如果是这种情况，内联这个函数将会确实带来更小的目标代码和更高的缓存命中率！

要牢记在心的一条是，inline指令就象register，它只是对编译器的一种提示，而不是命令。也就是说，只要编译器愿意，它就可以随意地忽略掉你的指令，事实上编译器常常会这么做。例如，大多数编译器拒绝内联”复杂”的函数（例如，包含循环和递归的函数）；还有，即使是最简单的虚函数调用，编译器的内联处理程序对它也爱莫能助**。（这一点也不奇怪。virtual的意思是”等到运行时再决定调用哪个函数”，inline的意思是”在编译期间将调用之处用被调函数来代替”，如果编译器甚至还不知道哪个函数将被调用，当然就不能责怪它拒绝生成内联调用了）**。以上可以归结为：一个给定的内联函数是否真的被内联取决于所用的编译器的具体实现。幸运的是，大多数编译器都可以设置诊断级，当声明为内联的函数实际上没有被内联时，编译器就会为你发出警告信息（参见条款48）。

假设写了某个函数f并声明为inline，如果出于什么原因，编译器决定不对它内联，那将会发生些什么呢？最明显的一个回答是将f作为一个非内联函数来处理：为f生成代码时就象它是一个普通的”外联”函数一样， 对f的调用也象对普通函数调用那样进行。

理论上来说确实应该这样发生，但理论和现实往往会偏离，现在就属于这种情况。因为，这个方案对解决”被外联的内联”（outlined inline）这一问题确实非常理想，但它加入到C++标准中的时间相对较晚。较早的C++规范（比如ARM——参见条款50）告诉编译器制造商去实现的是另外不同的行为，而且这一旧的行为在现在的编译器中还很普遍，所以必须理解它是怎么一回事。

稍微想一想你就可以记起，内联函数的定义实际上都是放在头文件中。这使得多个要编译的单元（源文件）可以包含同一个头文件，共享头文件内定义的内联函数所带来的益处。下面给出了一个例子，例子中的源文件名以常规的”.cpp”结尾，这应该是C++世界最普遍的命名习惯了：

// 文件example.h  
inline void f() \{ … \} // f的定义

…

// 文件source1.cpp  
\#include “example.h” // 包含f的定义

… // 包含对f的调用

// 文件source2.cpp  
\#include “example.h” // 也包含f的定义

… // 也调用f  
假设现在采用旧的”被外联的内联”规则，而且假设f没有被内联，那么，当source1.cpp被编译时，生成的目标文件中将包含一个称为f的函数，就象f没有被声明为inline一样。同样地，当source2.cpp被编译时，产生的目标文件也将包含一个称为f的函数。当想把两个目标文件链接在一起时，编译器会因为程序中有两个f的定义而报错。

为了防止这一问题，旧规则规定，对于未被内联的内联函数，编译器把它当成被声明为static那样处理，即，使它局限于当前被编译的文件。具体到刚才看到的例子中，遵循旧规则的编译器处理source1.cpp中的f时，就象f在source1.cpp中是静态的一样；处理source2.cpp中的f时，也把它当成在source2.cpp中是静态的一样。这一策略消除了链接时的错误，但带来了开销：每个包含f的定义（以及调用f）的被编译单元都包含自己的f的静态拷贝。如果f自身定义了局部静态变量，那么，每个f的拷贝都有此局部变量的一份拷贝，这必然会让程序员大吃一惊，因为一般来说，函数中的”static”意味着”只有一份拷贝”。

具体实现起来也会令人吃惊。无论新规则还是旧规则，如果内联函数没被内联，每个调用内联函数的地方还是得承担函数调用的开销；如果是旧规则，还得忍受代码体积的增加，因为每个包含（或调用） f的被编译单元都有一份f的代码及其静态变量的拷贝！（更糟糕的是，每个f的拷贝以及每个f的静态变量的拷贝往往处于不同的虚拟内存页面，所以两个对f的不同拷贝进行调用有可能导致多个页面错误。）

还有呢！有时，可怜的随时准备为您效劳的编译器即使很想内联一个函数，却不得不为这个内联函数生成一个函数体。特别是，如果程序中要取一个内联函数的地址，编译器就必须为此生成一个函数体。编译器怎么能产生一个指向不存在的函数的指针呢？

inline void f() \{…\} // 同上  
void (\*pf)() = f; // pf指向f  
int main()  
\{  
f(); // 对f的内联调用  
pf(); // 通过pf对f的非内联调用  
…  
\}  
这种情况似乎很荒谬：f的调用被内联了，但在旧的规则下，每个取f地址的被编译单元还是各自生成了此函数的静态拷贝。（新规则下，不管涉及的被编译单元有多少，将只生成唯一一个f的外部拷贝）

即使你从来不使用函数指针，这类”没被内联的内联函数”也会找上你的门，因为不只是程序员会使用函数指针，有时编译器也这么做。特别是，编译器有时会生成构造函数和析构函数的外部拷贝，这样就可以通过得到那些函数的指针，方便地构造和析构类的对象数组（参见条款M8）。

实际上，随便一个测试就可以证明构造函数和析构函数常常不适合内联；甚至，情况比测试结果还糟。例如，看下面这个类Derived的构造函数：

class Base \{  
public:  
…  
private:  
string bm1, bm2; // 基类成员1和2  
\};  
class Derived: public Base \{  
public:  
Derived() \{\} // Derived的构造函数是空的，  
… // ——但，真的是空的吗？  
private:  
string dm1, dm2, dm3; // 派生类成员1-3  
\};  
这个构造函数看起来的确象个内联的好材料，因为它没有代码。但外表常常欺骗人！仅仅因为它没有代码并不能说明它真的不含代码。实际上，它含有相当多的代码。

C++就对象创建和销毁时发生的事件有多方面的规定。条款5和M8介绍了当使用new时，动态创建的对象怎样自动地被它们的构造函数初始化，以及当使用delete时析构函数怎样被调用。条款13说明了当创建一个对象时，对象的每个基类以及对象的每个数据成员会被自动地创建；当对象被销毁时，会自动地执行相反的过程（即析构）。这些条款告诉你，C++规定了哪些必须发生，但没规定”怎么”发生。”怎么发生”取决于编译器的实现者，但要弄清楚的是，这些事件不是凭空自己发生的。程序中必然有什么代码使得它们发生，特别是那些由编译器的实现者写的、在编译其间插入到你的程序中的代码，必然也藏身于某个地方——有时，它们就藏身于你的构造函数和析构函数。所以，对于上面那个号称为空的Derived的构造函数，有些编译器会为它产生相当于下面的代码：

// 一个Derived构造函数的可能的实现  
Derived::Derived()  
\{  
// 如果在堆上创建对象，为其分配堆内存；  
// operator new的介绍参见条款8  
if (本对象在堆上)  
this = ::operator new(sizeof(Derived));  
Base::Base(); // 初始化Base部分  
dm1.string(); // 构造dm1  
dm2.string(); // 构造dm2  
dm3.string(); // 构造dm3  
\}  
别指望上面这样的代码可以通过编译，因为它在C++中是不合法的。首先，在构造函数内无法知道对象是不是在堆上。（想知道如何可靠地确定一个对象是否在堆上，请参见条款M27）另外，对this赋值是非法的。还有，通过函数调用访问构造函数也是不允许的。然而，编译器工作起来没这些限制，它可以随心所欲。但代码的合法性不是现在要讨论的主题。问题的要点在于，调用operator new（如果需要的话）的代码、构造基类部分的代码、构造数据成员的代码都会神不知鬼不觉地添加到你的构造函数中，从而增加构造函数的体积，使得构造函数不再适合内联。当然，同样的分析也适用于Base的构造函数，如果Base的构造函数被内联，添加到它里面的所有代码也会被添加到Derived的构造函数（Derived的构造函数会调用Base的构造函数）。如果string的构造函数恰巧也被内联，Derived的构造函数将得到其代码的5个拷贝，每个拷贝对应于Derived对象中5个string中的一个（2个继承而来，3个自己声明）。现在你应该明白，内联Derived的构造函数并非可以很简单就决定的！当然，类似的情况也适用于Derived的析构函数，无论如何都要清楚这一点：被Derived的构造函数初始化的所有对象都要被完全销毁。刚被销毁的对象以前可能占用了动态分配的内存，那么这些内存还需要释放。

程序库的设计者必须预先估计到声明内联函数带来的负面影响。因为想对程序库中的内联函数进行二进制代码升级是不可能的。换句话说，如果f是库中的一个内联函数，用户会将f的函数体编译到自己的程序中。如果程序库的设计者后来要修改f，所有使用f的用户程序必须重新编译。这会很令人讨厌（参见条款34）。相反，如果f是非内联函数，对f的修改仅需要用户重新链接，这就比需要重新编译大大减轻了负担；如果包含这个函数的程序库是被动态链接的，程序库的修改对用户来说完全是透明的。

内联函数中的静态对象常常表现出违反直觉的行为。所以，如果函数中包含静态对象，通常要避免将它声明为内联函数。具体介绍参见条款M26。

为了提高程序开发质量，以上诸项一定要牢记在心。但在具体编程时，从纯实际的角度来看，有一个事实比其余的因素都重要：大多数调试器遇上内联函数都会无能为力。

这不是什么新鲜事。你想，怎么在一个不存在的函数里设置断点呢？怎么单步执行到这样一个函数呢？怎么俘获对它的调用呢？除非你是个百年一遇的怪才，或者用了暗渡陈仓之类的伎俩，否则是不可能做到的。让人高兴的是，这一点倒是可以作为决定该不该对函数声明inline的决策依据之一。

一般来说，实际编程时最初的原则是不要内联任何函数，除非函数确实很小很简单，象下面这个age函数：

class Person \{  
public:  
int age() const \{ return personAge; \}  
…  
private:  
int personAge;  
…  
\};  
慎重地使用内联，不但给了调试器更多发挥作用的机会，还将内联的作用定位到了正确的位置：它是一个根据需要而使用的优化工具。不要忘了从无数经验得到的这条80-20定律（参见条款M16）：一个程序往往花80%的时间来执行程序中20%的代码。这是一条很重要的定律，因为它提醒你，作为程序员的一个很重要的目标，就是找出这20%能够真正提高整个程序性能的代码。你可以选择内联你的函数，或者没必要就不内联，但这些选择只有作用在”正确”的函数上才有意义。

一旦找出了程序中那些重要的函数，以及那些内联后可以确实提高程序性能的函数（这些函数本身依赖于所在系统的体系结构），就要毫不犹豫地声明为inline。同时，要注意代码膨胀带来的问题，并监视编译器的警告信息（参见条款48），看看是否有内联函数没有被编译器内联。

若能做到明智地使用，内联函数将是每个C++程序员百宝箱中的一件无价之宝。当然，正如前面的讨论所揭示的，它们并不象所想象的那样简单和直接。