内联函数机制解析

以下来源：http://blog.csdn.net/fuzhongmin05/article/details/54615865

内联函数机制的引入

        内联机制被引入C++作为对宏（Macro）机制的改进和补充（不是取代）。内联函数的参数传递机制与普通函数相同。但是编译器会在每处调用内联函数的地方将内联函数的内容展开。这样既避免了函数调用的开销又没有宏定义机制的缺陷。由此可见，内联函数机制的引入与宏定义有很大关系，因此，有必要先了解下宏定义有哪些缺陷。

        1. 由于宏定义都是直接嵌入代码中的，所以代码可能相对多一点；

        2. 嵌套定义过多可能会影响程序的可读性，而且很容易出错；

        3. 对带参的宏而言，由于是直接替换，并不会检查参数是否合法，存在安全隐患，预编译语句仅仅是简单的值代替，缺乏类型的检测机制。这样预处理语句就不能享受C++严格的类型检查的好处，从而可能成为引发一系列错误的隐患。

        最后引用《C陷进与缺陷》的一句话，对其进行总结：“宏并不是函数，宏并不是语句，宏并不是类型定义 ”。

inline关键字

        但是程序代码中的关键字”inline”只是对编译器的建议：被”inline”修饰的函数不一定被内联（但是无”inline”修饰的函数一定不是）。

        许多书上都会提到这是因为编译器比绝大多数程序员都更清楚函数调用的开销有多大，所以如果编译器认为调用某函数的开销相对该函数本身的开销而言微不足道或者不足以为之承担代码膨胀的后果则没必要内联该函数。这当然有一定道理，但是按照C、C++一脉相承的赋予程序员充分自由与决定权的风格来看，理由还不够充分。我猜想最主要的原因是为了避免编译器陷入无穷递归。如果内联函数之间存在递归调用则可能导致编译器展开内联函数时陷入无穷递归。有时候函数的递归调用十分隐蔽，程序员并不容易发现，所以简单起见，将内联函数展开与否的决定权交给编译器。

        开发人员有两种方式告诉编译器需要内联哪些函数，一种是在类的定义体外，一种是在类的定义体内。

        （2）当在类的定义体内且声明该成员函数时，同时提供成员函数的实现体。此时“inline”关键字不是必需的。

        因为C++是以“编译单元”为单位编译的，而一个编译单元往往大致等于一个“.cpp”文件。在实际编译前，预处理器会将“#include”的各个头文件的内容（可能会有递归头文件展开）完整地复制到cpp文件对应位置处（另外还会进行宏展开等操作）。预处理器处理后，编译真正开始。一旦C++编译器开始编译，它不会意识到其他cpp文件的存在。因此并不会参考其他cpp文件的内容信息。联想到内联的工作是由编译器完成的，且内联的意思是将被调用的内联函数的函数体代码直接代替对该内联函数的调用。这也就意味着，在编译某个编译单元时，如果该编译单元会调用到某个内联函数，那么该内联函数的函数定义（即函数体）必须也包含在该编译单元内。因为编译器使用内联函数体代码替代内联函数调用时，必须知道该内联函数的函数体代码，而且不能通过参考其他编译单元信息来获取这一信息。

        如果有多个编译单元会调用到同一个内联函数，C++规范要求在这多个编译单元中该内联函数的定义必须完全一致的。考虑到代码的维护性，最好将内联函数的定义放在一个头文件中，用到该内联函数的各个编译单元只需#include（包含）该头文件即可，进一步考虑，如果该内联函数是一个类的成员函数，这个头文件正好可以是该成员函数所属类的声明所在的头文件。

内联函数什么时候不展开

        在内联函数内不允许用循环语句和开关语句(开关语句即switch语句)。如果内联函数有这些语句，则编译将该函数视同普通函数那样产生函数调用代码，递归函数(自己调用自己的函数)是不能被用来做内联函数的。内联函数只适合于只有1～5行的小函数。对一个含有许多语句的大函数，函数调用和返回的开销相对来说微不足道，也没有必要用内联函数实现。

        另一种不被内联的情况是使用函数指针来调用内联函数（解释见引申部分）。

        对于C++中内联机制的一个常见误解是：关键字”inline”只是对编译器的建议，如果编译器发现指定的函数不适合内联就不会内联；所以即使内联使用得不恰当也不会有任何副作用。这句话只对了一半，内联使用不恰当是会有副作用的：会带来代码膨胀，还有可能引入难以发现的程序臭虫。

        根据规范，当编译器认为希望被内联的函数不适合内联的时候，编译器可以不内联该函数。但是不内联该函数不代表该函数就是一个普通函数了，从编译器的实际实现上来讲，内联失败的函数与普通函数是有区别的：

        （1）普通函数在编译时被单独编译一个对象，包含在相应的目标文件中。目标文件链接时，函数调用被链接到该对象上。

        （2）若一个函数被声明成内联函数，编译器即使遇到该函数的声明也不会为该函数编译出一个对象，因为内联函数是在用到的地方展开的。可是若在调用该内联函数的地方发现该内联函数的不适合展开时怎么办？一种选择是在调用该内联函数的目标文件中为该内联函数编译一个对象。这么做的直接后果是：若在多个文件调用了内联失败的函数，其中每个文件对应的目标文件中都会包含一份该内联函数的目标代码。

        如果编译器真的选择了上面的做法对待内联失败的函数，那么最好的情况是：没吃到羊肉，反惹了一身骚。即内联的好处没享受到，缺点却承担了：目标代码的体积膨胀得与成功内联的目标代码一样，但目标代码的效率确和没内联一样。

        更糟的是由于存在多份函数目标代码带来一些程序臭虫。最明显的例子是：内联失败的函数内的静态变量实际上就不在只有一份，而是有若干份。这显然是个错误，但是如果不了解内幕就很难找到原因。

宏定义与内联函数的区别

        从内联即函数体代码替代对该函数的调用这一本质看，它与C语言中的宏极其相似，但是它们之间有本质区别。宏代码本身不是函数，但使用起来却像函数，预处理器用复制宏代码的方式代替函数调用，省去了参数压栈、生成汇编语言的CALL调用、返回参数、执行return等过程，从而提高了速度。内联函数是代码被插入到调用者代码处的函数。对C++而言，内联函数的作用也不是万能的，它的使用是有所限制的，它只适合函数体内代码简单的函数使用，不能包含复杂的结构控制语句（如switch、while），并且内联函数本身不能直接调用递归函数。

        两者的区别主要表现在以下几个方面：第一，宏定义在预处理阶段进行代码替换，而内联函数是在编译阶段插入代码；第二，宏定义没有类型检查，而内联函数有类型检查，这对于写出正确且鲁棒的程序是一个很大的优势；最后，宏肯定会被展开，而用inline关键字修饰的函数不一定会被内联展开。

内联函数与普通函数的区别有哪些

        内联函数的参数传递机制与普通函数相同，但是编译器会在每处调用内联函数的地方将内联函数的内容展开，这样既避免了函数调用的开销又没有宏机制的缺陷。

        内联函数和普通函数的最大区别在于其内部的实现，普通函数在被调用时，系统首先要跳跃到函数的入口地址，执行函数体，执行完毕后，再返回到函数调用的地方，函数始终只有一个复制；而内联函数则不需要进行一个寻址过程，当执行内联函数时，此函数展开，如果在N处调用了此内联函数，则此函数就会有N个代码段的复制。

        空间和时间比较，假设调用一个函数之前的准备工作和之后的善后工作的指令所需空间大小为SS，执行这些代码所需时间为TS。

        （1）空间。如果一个函数的函数体代码大小为AS，在程序中被调用N次，不采用内联的情况下，空间开销为：SS*N+AS。采用内联：AS*N。因为N一般很大，所以它们之间的比较就是SS跟AS的比较，得出的结论是：如果SS小于AS，不采用内联，空间开销更少。如果AS小于SS，则采用内联，空间开销更少。

        （2）时间。内联之后每次调用不再需要做函数调用的准备和善后工作；内联之后编译器获得更多的代码信息，看到的是调用函数与被调用函数连成的一大块代码，此时编译器对代码的优化可以做得更好。还有一个很重要的因素，即内联后调用函数体内需要执行的代码是相邻的，其执行的代码都在同一个页面或连续的页面中。如果没有内联，执行到被调用函数时，需要跳到包含被调用函数的内存页面中执行，而被调用函数所属的页面极有可能当时不在物理内存中。这意味着，内联后可以降低“缺页”的几率，“缺页”次数的减少带来的效果远好于代码量的减少。另外即使被调用函数所在的页面可能正好在物理内存中，但是因为与调用函数在空间上相隔甚远，所以可能会引起“Cache miss”，从而降低执行速度。因此总的来说，内联后程序的执行时间会比没有内联要少，即程序速度更快。不过，如果内联的函数非常大的话，正如前面提到的，当AS远大于SS，且N很大时，会使最终程序的代码量增多，代码量多意味着用来存放代码的内存页面增多，“缺页”也会相应增加，速度反而下降，所以很大的函数不适合内联。这也是为什么很多编译器对于函数体代码很多的函数，会拒绝对其进行内联的请求。即忽略”inline”关键字，而对如同普通函数那样编译。

        最后顺带提及，一个程序的唯一入口main()函数肯定不会被内联化。另外编译器合成的默认构造函数、拷贝构造函数、析构函数以及赋值运算符一般都被内联化。

以下来源：http://blog.csdn.net/u011327981/article/details/50601800

1.  内联函数

在C++中我们通常定义以下函数来求两个整数的最大值：

复制代码 代码如下:

int max(int a, int b)
{
 return a > b ? a : b;
}

为这么一个小的操作定义一个函数的好处有：

① 阅读和理解函数 max 的调用，要比读一条等价的条件表达式并解释它的含义要容易得多

② 如果需要做任何修改，修改函数要比找出并修改每一处等价表达式容易得多

③ 使用函数可以确保统一的行为，每个测试都保证以相同的方式实现

④ 函数可以重用，不必为其他应用程序重写代码

虽然有这么多好处，但是写成函数有一个潜在的缺点：调用函数比求解等价表达式要慢得多。在大多数的机器上，调用函数都要做很多工作：调用前要先保存寄存器，并在返回时恢复，复制实参，程序还必须转向一个新位置执行

C++中支持内联函数，其目的是为了提高函数的执行效率，用关键字 inline 放在函数定义(注意是定义而非声明，下文继续讲到)的前面即可将函数指定为内联函数，内联函数通常就是将它在程序中的每个调用点上“内联地”展开，假设我们将 max 定义为内联函数：

复制代码 代码如下:

inline int max(int a, int b)
{
 return a > b ? a : b;
}

则调用： cout<<max(a, b)<<endl;

在编译时展开为： cout<<(a > b ? a : b)<<endl;

从而消除了把 max写成函数的额外执行开销

2.  内联函数和宏

无论是《Effective C++》中的 “Prefer consts，enums，and inlines to #defines” 条款，还是《高质量程序设计指南——C++/C语言》中的“用函数内联取代宏”，宏在C++中基本是被废了，在书《高质量程序设计指南——C++/C语言》中这样解释到：

3.  将内联函数放入头文件

关键字 inline 必须与函数定义体放在一起才能使函数成为内联，仅将 inline 放在函数声明前面不起任何作用。

如下风格的函数 Foo 不能成为内联函数：

复制代码 代码如下:

inline void Foo(int x, int y);   // inline 仅与函数声明放在一起  
void Foo(int x, int y)
{
 …
}

而如下风格的函数 Foo 则成为内联函数：

复制代码 代码如下:

void Foo(int x, int y);  
inline void Foo(int x, int y)   // inline 与函数定义体放在一起
{
 …
}

所以说，C++ inline函数是一种“用于实现的关键字”，而不是一种“用于声明的关键字”。一般地，用户可以阅读函数的声明，但是看不到函数的定义。尽管在大多数教科书中内联函数的声明、定义体前面都加了 inline 关键字，但我认为 inline 不应该出现在函数的声明中。这个细节虽然不会影响函数的功能，但是体现了高质量C++/C 程序设计风格的一个基本原则：声明与定义不可混为一谈，用户没有必要、也不应该知道函数是否需要内联。

定义在类声明之中的成员函数将自动地成为内联函数，例如：

复制代码 代码如下:

class A
{ 
public:
 void Foo(int x, int y) { … }   // 自动地成为内联函数 
}

但是编译器是否将它真正内联则要看 Foo函数如何定义

内联函数应该在头文件中定义，这一点不同于其他函数。编译器在调用点内联展开函数的代码时，必须能够找到 inline 函数的定义才能将调用函数替换为函数代码，而对于在头文件中仅有函数声明是不够的。

当然内联函数定义也可以放在源文件中，但此时只有定义的那个源文件可以用它，而且必须为每个源文件拷贝一份定义(即每个源文件里的定义必须是完全相同的)，当然即使是放在头文件中，也是对每个定义做一份拷贝，只不过是编译器替你完成这种拷贝罢了。但相比于放在源文件中，放在头文件中既能够确保调用函数是定义是相同的，又能够保证在调用点能够找到函数定义从而完成内联(替换)。

但是你会很奇怪，重复定义那么多次，不会产生链接错误？

我们来看一个例子：

A.h :

复制代码 代码如下:

class A
{
public:
 A(int a, int b) : a(a),b(b){}
 int max();

private:
 int a;
 int b;
};

A.cpp :

复制代码 代码如下:

#include “A.h”

inline int A::max()
{
 return a > b ? a : b;
}

Main.cpp :

复制代码 代码如下:

#include <iostream>
#include “A.h”
using namespace std;

inline int A::max()
{
 return a > b ? a : b;
}

int main()
{
 A a(3, 5);
 cout<<a.max()<<endl;
 return 0;
}

一切正常编译，输出结果：5

 

倘若你在Main.cpp中没有定义max内联函数，那么会出现链接错误：

error LNK2001: unresolved external symbol “public: int __thiscall A::max(void)” (?max@A@@QAEHXZ)main.obj
找不到函数的定义，所以内联函数可以在程序中定义不止一次，只要 inline 函数的定义在某个源文件中只出现一次，而且在所有源文件中，其定义必须是完全相同的就可以。

在头文件中加入或修改 inline 函数时，使用了该头文件的所有源文件都必须重新编译。

4.  慎用内联

内联虽有它的好处，但是也要慎用，以下摘自《高质量程序设计指南——C++/C语言》：

而在Google C++编码规范中则规定得更加明确和详细：

内联函数：

Tip： 只有当函数只有 10 行甚至更少时才将其定义为内联函数.

定义: 当函数被声明为内联函数之后, 编译器会将其内联展开, 而不是按通常的函数调用机制进行调用.
优点: 当函数体比较小的时候, 内联该函数可以令目标代码更加高效. 对于存取函数以及其它函数体比较短, 性能关键的函数, 鼓励使用内联.
缺点: 滥用内联将导致程序变慢. 内联可能使目标代码量或增或减, 这取决于内联函数的大小. 内联非常短小的存取函数通常会减少代码大小, 但内联一个相当大的函数将戏剧性的增加代码大小. 现代处理器由于更好的利用了指令缓存, 小巧的代码往往执行更快。
结论: 一个较为合理的经验准则是, 不要内联超过 10 行的函数. 谨慎对待析构函数, 析构函数往往比其表面看起来要更长, 因为有隐含的成员和基类析构函数被调用!
另一个实用的经验准则: 内联那些包含循环或 switch 语句的函数常常是得不偿失 (除非在大多数情况下, 这些循环或 switch 语句从不被执行).
有些函数即使声明为内联的也不一定会被编译器内联, 这点很重要; 比如虚函数和递归函数就不会被正常内联. 通常, 递归函数不应该声明成内联函数.(递归调用堆栈的展开并不像循环那么简单, 比如递归层数在编译时可能是未知的, 大多数编译器都不支持内联递归函数). 虚函数内联的主要原因则是想把它的函数体放在类定义内, 为了图个方便, 抑或是当作文档描述其行为, 比如精短的存取函数.

-inl.h文件：

Tip： 复杂的内联函数的定义, 应放在后缀名为 -inl.h 的头文件中.

内联函数的定义必须放在头文件中, 编译器才能在调用点内联展开定义. 然而, 实现代码理论上应该放在 .cc 文件中, 我们不希望 .h 文件中有太多实现代码, 除非在可读性和性能上有明显优势.

如果内联函数的定义比较短小, 逻辑比较简单, 实现代码放在 .h 文件里没有任何问题. 比如, 存取函数的实现理所当然都应该放在类定义内. 出于编写者和调用者的方便, 较复杂的内联函数也可以放到 .h 文件中, 如果你觉得这样会使头文件显得笨重, 也可以把它萃取到单独的 -inl.h 中. 这样把实现和类定义分离开来, 当需要时包含对应的 -inl.h 即可。

                </div>