c++内联函数(inline)及内联函数的使用及注意点

以下转自：http://www.jb51.net/article/48622.htm

介绍内联函数之前，有必要介绍一下预处理宏。内联函数的功能和预处理宏的功能相似。相信大家都用过预处理宏，我们会经常定义一些宏，如

复制代码 代码如下:

#define TABLE_COMP(x) ((x)>0?(x):0)

就定义了一个宏。

为什么要使用宏呢？因为函数的调用必须要将程序执行的顺序转移到函数所存放在内存中的某个地址，将函数的程序内容执行完后，再返回到转去执行该函数前的地方。这种转移操作要求在转去执行前要保存现场并记忆执行的地址，转回后要恢复现场，并按原来保存地址继续执行。因此，函数调用要有一定的时间和空间方面的开销，于是将影响其效率。而宏只是在预处理的地方把代码展开，不需要额外的空间和时间方面的开销，所以调用一个宏比调用一个函数更有效率。
但是宏也有很多的不尽人意的地方。
1、宏不能访问对象的私有成员。
2、宏的定义很容易产生二意性。
我们举个例子：

复制代码 代码如下:

#define TABLE_MULTI(x) (x*x)

我们用一个数字去调用它,TABLE_MULTI(10)，这样看上去没有什么错误，结果返回100,是正确的，但是如果我们用TABLE_MULTI(10+10)去调用的话，我们期望的结果是４００，而宏的调用结果是(10+10*10+10),结果是120，这显然不是我们要得到的结果。避免这些错误的方法，一是给宏的参数都加上括号。

复制代码 代码如下:

#define TABLE_MULTI(x) ((x)*(x))

这样可以确保不会出错，但是，即使使用了这种定义，这个宏依然有可能出错，例如使用TABLE_MULTI(a++)调用它，他们本意是希望得到(a+1)*(a+1)的结果，而实际上呢？我们可以看看宏的展开结果: (a++)*(a++)，如果a的值是４，我们得到的结果是5*6=30。而我们期望的结果是5*5=25,这又出现了问题。事实上，在一些C的库函数中也有这些问题。例如: Toupper(*pChar++)就会对pChar执行两次++操作，因为Toupper实际上也是一个宏。
我们可以看到宏有一些难以避免的问题，怎么解决呢？
下面就是用我要介绍的内联函数来解决这些问题，我们可以使用内联函数来取代宏的定义。而且事实上我们可以用内联函数完全取代预处理宏。
内联函数和宏的区别在于，宏是由预处理器对宏进行替代，而内联函数是通过编译器控制来实现的。而且内联函数是真正的函数，只是在需要用到的时候，内联函数像宏一样的展开，所以取消了函数的参数压栈，减少了调用的开销。你可以象调用函数一样来调用内联函数，而不必担心会产生于处理宏的一些问题。
我们可以用Inline来定义内联函数，不过，任何在类的说明部分定义的函数都会被自动的认为是内联函数。
下面我们来介绍一下内联函数的用法。
内联函数必须是和函数体申明在一起，才有效。像这样的申明Inline Tablefunction(int I)是没有效果的，编译器只是把函数作为普通的函数申明，我们必须定义函数体。

复制代码 代码如下:

Inline tablefunction(int I) {return I*I};

这样我们才算定义了一个内联函数。我们可以把它作为一般的函数一样调用。但是执行速度确比一般函数的执行速度要快。
我们也可以将定义在类的外部的函数定义为内联函数，比如：

复制代码 代码如下:

Class TableClass{
　Private:
Int I,j;
　Public:
Int add() { return I+j;};
Inline int dec() { return I-j;}
Int GetNum();
}
inline int tableclass::GetNum(){
return I;
}

上面申明的三个函数都是内联函数。在C++中，在类的内部定义了函数体的函数，被默认为是内联函数。而不管你是否有inline关键字。
内联函数在C++类中，应用最广的，应该是用来定义存取函数。我们定义的类中一般会把数据成员定义成私有的或者保护的，这样，外界就不能直接读写我们类成员的数据了。对于私有或者保护成员的读写就必须使用成员接口函数来进行。如果我们把这些读写成员函数定义成内联函数的话，将会获得比较好的效率。

复制代码 代码如下:

Class sample{
　Private:
Int nTest;
　Public:
Int readtest(){ return nTest;}
　Void settest(int I) {nTest=I;}
}

当然，内联函数也有一定的局限性。就是函数中的执行代码不能太多了，如果，内联函数的函数体过大，一般的编译器会放弃内联方式，而采用普通的方式调用函数。这样，内联函数就和普通函数执行效率一样了。

以下转自：http://www.cnblogs.com/xkfz007/archive/2012/03/27/2420166.html

内联函数并不总是内联 Inline function是在C++中引入的一种机制，它可以拓展函数代码，避免调用函数的额外开销。在Linux环境下，gcc编译选项必须加上优化选项才能使inline有效。

1. inline与static的关系

   在这儿有一个比较详细的分析：http://www.cnblogs.com/xkfz007/articles/2370640.html

2. 内联函数（inline）机制与陷阱

   内联机制被引入C++作为对宏（Macro）机制的改进和补充（不是取代）。内联函数的参数传递机制与普通函数相同。但是编译器会在每处调用内联函数的地方将内联函数的内容展开。这样既避免了函数调用的开销又没有宏机制的前三个缺陷。

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

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

    

   另一种不被内联的情况是使用函数指针来调用内联函数。

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

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

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

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

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

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