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）若一個函數被聲明成内聯函數，編譯器即使遇到該函數的聲明也不會為該函數編譯出一個對象，因為内聯函數是在用到的地方展開的。可是若在調用該内聯函數的地方發現該内聯函數的不适合展開時怎麼辦？一種選擇是在調用該内聯函數的目标檔案中為該内聯函數編譯一個對象。這麼做的直接後果是：若在多個檔案調用了内聯失敗的函數，其中每個檔案對應的目标檔案中都會包含一份該内聯函數的目标代碼。

   如果編譯器真的選擇了上面的做法對待内聯失敗的函數，那麼最好的情況是：沒吃到羊肉，反惹了一身騷。即内聯的好處沒享受到，缺點卻承擔了：目标代碼的體積膨脹得與成功内聯的目标代碼一樣，但目标代碼的效率确和沒内聯一樣。

   更糟的是由于存在多份函數目标代碼帶來一些程式臭蟲。最明顯的例子是：内聯失敗的函數内的靜态變量實際上就不在隻有一份，而是有若幹份。這顯然是個錯誤，但是如果不了解内幕就很難找到原因。