在C中為什么要使用宏呢？
因?yàn)楹瘮?shù)的調(diào)用必須要將程序執(zhí)行的順序轉(zhuǎn)移到函數(shù)所存放在內(nèi)存中的某個(gè)地址，將函數(shù)的程序內(nèi)容執(zhí)行完后，再返回到轉(zhuǎn)去執(zhí)行該函數(shù)前的地方。這種轉(zhuǎn)移操作要求在轉(zhuǎn)去執(zhí)行前要保存現(xiàn)場并記憶執(zhí)行的地址，轉(zhuǎn)回后要恢復(fù)現(xiàn)場，并按原來保存地址繼續(xù)執(zhí)行。因此，函數(shù)調(diào)用要有一定的時(shí)間和空間方面的開銷，于是將影響其效率。
而宏只是在預(yù)處理的地方把代碼展開，不需要額外的空間和時(shí)間方面的開銷，所以調(diào)用一個(gè)宏比調(diào)用一個(gè)函數(shù)更有效率。
宏和函數(shù)的區(qū)別：
1. 宏做的是簡單的字符串替換(注意是字符串的替換,不是其他類型參數(shù)的替換),而函數(shù)的參數(shù)的傳遞,參數(shù)是有數(shù)據(jù)類型的,可以是各種各樣的類型.
2. 宏的參數(shù)替換是不經(jīng)計(jì)算而直接處理的,而函數(shù)調(diào)用是將實(shí)參的值傳遞給形參,既然說是值,自然是計(jì)算得來的.
3. 宏在編譯之前進(jìn)行,即先用宏體替換宏名,然后再編譯的,而函數(shù)顯然是編譯之后,在執(zhí)行時(shí),才調(diào)用的.因此,宏占用的是編譯的時(shí)間,而函數(shù)占用的是執(zhí)行時(shí)的時(shí)間.
4. 宏的參數(shù)是不占內(nèi)存空間的,因?yàn)橹皇亲鲎址奶鎿Q,而函數(shù)調(diào)用時(shí)的參數(shù)傳遞則是具體變量之間的信息傳遞,形參作為函數(shù)的局部變量,顯然是占用內(nèi)存的.
5. 函數(shù)的調(diào)用是需要付出一定的時(shí)空開銷的,因?yàn)橄到y(tǒng)在調(diào)用函數(shù)時(shí),要保留現(xiàn)場,然后轉(zhuǎn)入被調(diào)用函數(shù)去執(zhí)行,調(diào)用完,再返回主調(diào)函數(shù),此時(shí)再恢復(fù)現(xiàn)場,這些操作,顯然在宏中是沒有的.
宏也有很多的不盡人意的地方。
1、宏不能訪問對象的私有成員。
2、宏的定義很容易產(chǎn)生二意性。
我們舉個(gè)例子：
#define square(x) (x*x)
我們用一個(gè)數(shù)字去調(diào)用它,square(5)，這樣看上去沒有什么錯(cuò)誤，結(jié)果返回25,是正確的，但是如果我們用squre (5+5)去調(diào)用的話，我們期望的結(jié)果是100，而宏的調(diào)用結(jié)果是(5+5*5+5),結(jié)果是35，這顯然不是我們要得到的結(jié)果。避免這些錯(cuò)誤的方法，一是給宏的參數(shù)都加上括號。
#define square(x) ((x)*(x))
這樣可以確保不會出錯(cuò)，但是，即使使用了這種定義，這個(gè)宏依然有可能出錯(cuò)，例如使用TABLE_MULTI(a++)調(diào)用它，他們本意是希望得到(a+1)*(a+1)的結(jié)果，而實(shí)際上呢？我們可以看看宏的展開結(jié)果: (a++)*(a++)，如果a的值是４，我們得到的結(jié)果是6*6=36。而我們期望的結(jié)果是5*5=25,這又出現(xiàn)了問題。事實(shí)上，在一些C的庫函數(shù)中也有這些問題。例如: Toupper(*pChar++)就會對pChar執(zhí)行兩次++操作，因?yàn)門oupper實(shí)際上也是一個(gè)宏。
我們可以看到宏有一些難以避免的問題，怎么解決呢？
下面就是用我要介紹的內(nèi)聯(lián)函數(shù)來解決這些問題，我們可以使用內(nèi)聯(lián)函數(shù)來取代宏的定義。而且事實(shí)上我們可以用內(nèi)聯(lián)函數(shù)完全取代預(yù)處理宏。
內(nèi)聯(lián)函數(shù)和宏的區(qū)別在于，宏是由預(yù)處理器對宏進(jìn)行替代，而內(nèi)聯(lián)函數(shù)是通過編譯器控制來實(shí)現(xiàn)的。而且內(nèi)聯(lián)函數(shù)是真正的函數(shù)，只是在需要用到的時(shí)候，內(nèi)聯(lián)函數(shù)像宏一樣的展開，所以取消了函數(shù)的參數(shù)壓棧，減少了調(diào)用的開銷。你可以象調(diào)用函數(shù)一樣來調(diào)用內(nèi)聯(lián)函數(shù)，而不必?fù)?dān)心會產(chǎn)生于處理宏的一些問題。
我們可以用inline來定義內(nèi)聯(lián)函數(shù)，不過，任何在類的說明部分定義的函數(shù)都會被自動的認(rèn)為是內(nèi)聯(lián)函數(shù)。
下面我們來介紹一下內(nèi)聯(lián)函數(shù)的用法。
內(nèi)聯(lián)函數(shù)必須是和函數(shù)體申明在一起，才有效。像這樣的申明 inline Tablefunction(int i) 是沒有效果的，編譯器只是把函數(shù)作為普通的函數(shù)申明，我們必須定義函數(shù)體。
inline tablefunction(int i)
{
return i*i
};
這樣我們才算定義了一個(gè)內(nèi)聯(lián)函數(shù)。我們可以把它作為一般的函數(shù)一樣調(diào)用。但是執(zhí)行速度確比一般函數(shù)的執(zhí)行速度要快。
我們也可以將定義在類的外部的函數(shù)定義為內(nèi)聯(lián)函數(shù)，比如：
class tableClass{
private:
int i,j;
public:
int add() { return iI+j;};
inline int dec() { return i-j;}
int GetNum();
}
inline int tableclass::GetNum(){
return i;
}
上面申明的三個(gè)函數(shù)都是內(nèi)聯(lián)函數(shù)。在C++中，在類的內(nèi)部定義了函數(shù)體的函數(shù)，被默認(rèn)為是內(nèi)聯(lián)函數(shù)。而不管你是否有inline關(guān)鍵字。
內(nèi)聯(lián)函數(shù)在C++類中，應(yīng)用最廣的，應(yīng)該是用來定義存取函數(shù)。我們定義的類中一般會把數(shù)據(jù)成員定義成私有的或者保護(hù)的，這樣，外界就不能直接讀寫我們類成員的數(shù)據(jù)了。對于私有或者保護(hù)成員的讀寫就必須使用成員接口函數(shù)來進(jìn)行。如果我們把這些讀寫成員函數(shù)定義成內(nèi)聯(lián)函數(shù)的話，將會獲得比較好的效率。
class sample{
private:
int nTest;
public:
int readtest(){ return nTest; }
void settest(int i) { nTest=i; }
}
當(dāng)然，內(nèi)聯(lián)函數(shù)也有一定的局限性。就是函數(shù)中的執(zhí)行代碼不能太多了，如果，內(nèi)聯(lián)函數(shù)的函數(shù)體過大，一般的編譯器會放棄內(nèi)聯(lián)方式，而采用普通的方式調(diào)用函數(shù)。這樣，內(nèi)聯(lián)函數(shù)就和普通函數(shù)執(zhí)行效率一樣了。
下面再舉一個(gè)例子：
開發(fā)人員可以有兩種方式告訴編譯器需要內(nèi)聯(lián)哪些類成員函數(shù)，一種是在類的定義體外；一種是在類的定義體內(nèi)。
（1）當(dāng)在類的定義體外時(shí)，需要在該成員函數(shù)的定義前面加“inline”關(guān)鍵字，顯式地告訴編譯器該函數(shù)在調(diào)用時(shí)需要“內(nèi)聯(lián)”處理，如：
class Student
{
public:
String GetName();
int GetAge();
void SetAge(int ag);
……
private:
String name;
int age;
……
};
inline String GetName()
{
return name;
}
inline int GetAge()
{
return age;
}
inline void SetAge(int ag)
{
age = ag;
}
（2）當(dāng)在類的定義體內(nèi)且聲明該成員函數(shù)時(shí)，同時(shí)提供該成員函數(shù)的實(shí)現(xiàn)體。此時(shí)，“inline”關(guān)鍵字并不是必需的，如：
class Student
{
public:
String GetName() { return name; }
int GetAge() { return age; }
void SetAge(int ag) { age = ag; }
……
private:
String name;
int age;
……
};
當(dāng)普通函數(shù)（非類成員函數(shù)）需要被內(nèi)聯(lián)時(shí)，則只需要在函數(shù)的定義時(shí)前面加上“inline”關(guān)鍵字，如：
inline int DoSomeMagic(int a, int b)
{
return a * 13 + b % 4 + 3;
}
因?yàn)镃++是以“編譯單元”為單位編譯的，而一個(gè)編譯單元往往大致等于一個(gè)“.cpp”文件。在實(shí)際編譯前，預(yù)處理器會將“#include”的各頭文件的內(nèi)容（可能會有遞歸頭文件展開）完整地拷貝到cpp文件對應(yīng)位置處（另外還會進(jìn)行宏展開等操作）。預(yù)處理器處理后，編譯真正開始。一旦C++編譯器開始編譯，它不會意識到其他cpp文件的存在。因此并不會參考其他cpp文件的內(nèi)容信息。聯(lián)想到內(nèi)聯(lián)的工作是由編譯器完成的，且內(nèi)聯(lián)的意思是將被調(diào)用內(nèi)聯(lián)函數(shù)的函數(shù)體代碼直接代替對該內(nèi)聯(lián)函數(shù)的調(diào)用。這也就意味著，在編譯某個(gè)編譯單元時(shí)，如果該編譯單元會調(diào)用到某個(gè)內(nèi)聯(lián)函數(shù)，那么該內(nèi)聯(lián)函數(shù)的函數(shù)定義（即函數(shù)體）必須也包含在該編譯單元內(nèi)。因?yàn)榫幾g器使用內(nèi)聯(lián)函數(shù)體代碼替代內(nèi)聯(lián)函數(shù)調(diào)用時(shí)，必須知道該內(nèi)聯(lián)函數(shù)的函數(shù)體代碼，而且不能通過參考其他編譯單元信息來獲得這一信息。
如果有多個(gè)編譯單元會調(diào)用到某同一個(gè)內(nèi)聯(lián)函數(shù)，C++規(guī)范要求在這多個(gè)編譯單元中該內(nèi)聯(lián)函數(shù)的定義必須是完全一致的，這就是“ODR”（one-definition rule）原則?？紤]到代碼的可維護(hù)性，最好將內(nèi)聯(lián)函數(shù)的定義放在一個(gè)頭文件中，用到該內(nèi)聯(lián)函數(shù)的各個(gè)編譯單元只需#include該頭文件即可。進(jìn)一步考慮，如果該內(nèi)聯(lián)函數(shù)是一個(gè)類的成員函數(shù)，這個(gè)頭文件正好可以是該成員函數(shù)所屬類的聲明所在的頭文件。這樣看來，類成員內(nèi)聯(lián)函數(shù)的兩種聲明可以看成是幾乎一樣的，雖然一個(gè)是在類外，一個(gè)在類內(nèi)。但是兩個(gè)都在同一個(gè)頭文件中，編譯器都能在#include該頭文件后直接取得內(nèi)聯(lián)函數(shù)的函數(shù)體代碼。討論完如何聲明一個(gè)內(nèi)聯(lián)函數(shù)，來查看編譯器如何內(nèi)聯(lián)的。繼續(xù)上面的例子，假設(shè)有個(gè)foo函數(shù)：
#include "student.h"
...
void foo()
{
...
Student abc;
abc.SetAge(12);
cout << abc.GetAge();
...
}
foo函數(shù)進(jìn)入foo函數(shù)時(shí)，從其棧幀中開辟了放置abc對象的空間。進(jìn)入函數(shù)體后，首先對該處空間執(zhí)行Student的默認(rèn)構(gòu)造函數(shù)構(gòu)造abc對象。然后將常數(shù)12壓棧，調(diào)用abc的SetAge函數(shù)（開辟SetAge函數(shù)自己的棧幀，返回時(shí)回退銷毀此棧幀）。緊跟著執(zhí)行abc的GetAge函數(shù)，并將返回值壓棧。最后調(diào)用cout的<<操作符操作壓棧的結(jié)果，即輸出。
內(nèi)聯(lián)后大致如下:
#include "student.h"
...
void foo()
{
...
Student abc;
{
abc.age = 12;
}
int tmp = abc.age;
cout << tmp;
...
}
這時(shí)，函數(shù)調(diào)用時(shí)的參數(shù)壓棧、棧幀開辟與銷毀等操作不再需要，而且在結(jié)合這些代碼后，編譯器能進(jìn)一步優(yōu)化為如下結(jié)果：
#include "student.h"
...
void foo()
{
...
cout << 12;
...
}
這顯然是最好的優(yōu)化結(jié)果；相反，考慮原始版本。如果SetAge/GetAge沒有被內(nèi)聯(lián)，因?yàn)榉莾?nèi)聯(lián)函數(shù)一般不會在頭文件中定義，這兩個(gè)函數(shù)可能在這個(gè)編譯單元之外的其他編譯單元中定義。即foo函數(shù)所在編譯單元看不到SetAge/GetAge，不知道函數(shù)體代碼信息，那么編譯器傳入12給SetAge，然后用GetAge輸出。在這一過程中，編譯器不能確信最后GetAge的輸出。因?yàn)榫幾g這個(gè)編譯單元時(shí)，不知道這兩個(gè)函數(shù)的函數(shù)體代碼，因而也就不能做出最終版本的優(yōu)化。
從上述分析中，可以看到使用內(nèi)聯(lián)函數(shù)至少有如下兩個(gè)優(yōu)點(diǎn)。
（1）減少因?yàn)楹瘮?shù)調(diào)用引起開銷，主要是參數(shù)壓棧、棧幀開辟與回收，以及寄存器保存與恢復(fù)等。
（2）內(nèi)聯(lián)后編譯器在處理調(diào)用內(nèi)聯(lián)函數(shù)的函數(shù)（如上例中的foo()函數(shù)）時(shí)，因?yàn)榭晒┓治龅拇a更多，因此它能做的優(yōu)化更深入徹底。
第一條優(yōu)點(diǎn)對于開發(fā)人員來說往往更顯而易見一些，第二條優(yōu)點(diǎn)對最終代碼的優(yōu)化可能貢獻(xiàn)更大。
這時(shí)，有必要簡單介紹函數(shù)調(diào)用時(shí)都需要執(zhí)行哪些操作，這樣可以幫助分析一些函數(shù)調(diào)用相關(guān)的問題。假設(shè)下面代碼：
void foo()
{
...
i = func(a, b, c); ①
... ②
}
調(diào)用者（這里是foo）在調(diào)用前需要執(zhí)行如下操作。
（1）參數(shù)壓棧：這里是a、b和c。壓棧時(shí)一般都是按照逆序，因此是c->b->c。如果a、b和c有對象，則需要先進(jìn)行拷貝構(gòu)造。
（2）保存返回地址：即函數(shù)調(diào)用結(jié)束返回后接著執(zhí)行的語句的地址，這里是②處語句的地址。
（3）保存維護(hù)foo函數(shù)棧幀信息的寄存器內(nèi)容：如SP（堆棧指針）和FP（棧幀指針）等。到底保存哪些寄存器與平臺相關(guān)，但是每個(gè)平臺肯定都會有對應(yīng)的寄存器。
（4）保存一些通用寄存器的內(nèi)容：因?yàn)橛行┩ㄓ眉拇嫫鲿凰泻瘮?shù)用到，所以在foo調(diào)用func之前，這些寄存器可能已經(jīng)放置了對foo有用的信息。這些寄存器在進(jìn)入func函數(shù)體內(nèi)執(zhí)行時(shí)可能會被func用到，從而被覆寫。因此foo在調(diào)用func前保存一份這些通用寄存器的內(nèi)容，這樣在func返回后可以恢復(fù)它們。
接著調(diào)用func函數(shù)，它首先通過移動棧指針來分配所有在其內(nèi)部聲明的局部變量所需的空間，然后執(zhí)行其函數(shù)體內(nèi)的代碼等。
最后當(dāng)func執(zhí)行完畢，函數(shù)返回時(shí)，foo函數(shù)還需要執(zhí)行如下善后處理。
（1）恢復(fù)通用寄存器的值。
（2）恢復(fù)保存foo函數(shù)棧幀信息的那些寄存器的值。
（3）通過移動棧指針，銷毀func函數(shù)的棧幀，
（4）將保存的返回地址出棧，并賦給IP寄存器。
（5）通過移動棧指針，回收傳給func函數(shù)的參數(shù)所占用的空間。
我們知道，如果傳入?yún)?shù)和返回值為對象時(shí)，還會涉及對象的構(gòu)造與析構(gòu)，函數(shù)調(diào)用的開銷就會更大。尤其是當(dāng)傳入對象和返回對象是復(fù)雜的大對象時(shí)，更是如此。
因?yàn)楹瘮?shù)調(diào)用的準(zhǔn)備與善后工作最終都是由機(jī)器指令完成的，假設(shè)一個(gè)函數(shù)之前的準(zhǔn)備工作與之后的善后工作的指令所需的空間為SS，執(zhí)行這些代碼所需的時(shí)間為TS，現(xiàn)在可以更細(xì)致地從空間與時(shí)間兩個(gè)方面來分析內(nèi)聯(lián)的效果。
（1）在空間上，一般印象是不采用內(nèi)聯(lián)，被調(diào)用函數(shù)的代碼只有一份，調(diào)用它的地方使用call語句引用即可。而采用內(nèi)聯(lián)后，該函數(shù)的代碼在所有調(diào)用其處都有一份拷貝，因此最后總的代碼大小比采用內(nèi)聯(lián)前要大。但事實(shí)不總是這樣的，如果一個(gè)函數(shù)a的體代碼大小為AS，假設(shè)a函數(shù)在整個(gè)程序中被調(diào)用了n次，不采用內(nèi)聯(lián)時(shí)，對a的調(diào)用只有準(zhǔn)備工作與善后工作兩處會增加最后的代碼量開銷，即a函數(shù)相關(guān)的代碼大小為：n * SS + AS。采用內(nèi)聯(lián)后，在各處調(diào)用點(diǎn)都需要將其函數(shù)體代碼展開，即a函數(shù)相關(guān)的代碼大小為n * AS。這樣比較二者的大小，即比較(n * SS + AS)與(n*AS)的大小?？紤]到n一般次數(shù)很多時(shí)，可以簡化成比較SS與AS的大小。這樣可以得出大致結(jié)論，如果被內(nèi)聯(lián)函數(shù)自己的函數(shù)體代碼量比因?yàn)楹瘮?shù)調(diào)用的準(zhǔn)備與善后工作引入的代碼量大，內(nèi)聯(lián)后程序的代碼量會變大；相反，當(dāng)被內(nèi)聯(lián)函數(shù)的函數(shù)體代碼量比因?yàn)楹瘮?shù)調(diào)用的準(zhǔn)備與善后工作引入的代碼量小，內(nèi)聯(lián)后程序的代碼量會變小。這里還沒有考慮內(nèi)聯(lián)的后續(xù)情況，即編譯器可能因?yàn)楂@得的信息更多，從而對調(diào)用函數(shù)的優(yōu)化做得更深入和徹底，致使最終的代碼量變得更小。
（2）在時(shí)間上，一般而言，每處調(diào)用都不再需要做函數(shù)調(diào)用的準(zhǔn)備與善后工作。另外內(nèi)聯(lián)后，編譯器在做優(yōu)化時(shí)，看到的是調(diào)用函數(shù)與被調(diào)用函數(shù)連成的一大塊代碼。即獲得的代碼信息更多，此時(shí)它對調(diào)用函數(shù)的優(yōu)化可以做得更好。最后還有一個(gè)很重要的因素，即內(nèi)聯(lián)后調(diào)用函數(shù)體內(nèi)需要執(zhí)行的代碼是相鄰的，其執(zhí)行的代碼都在同一個(gè)頁面或連續(xù)的頁面中。如果沒有內(nèi)聯(lián)，執(zhí)行到被調(diào)用函數(shù)時(shí)，需要跳到包含被調(diào)用函數(shù)的內(nèi)存頁面中執(zhí)行，而被調(diào)用函數(shù)所屬的頁面極有可能當(dāng)時(shí)不在物理內(nèi)存中。這意味著，內(nèi)聯(lián)后可以降低“缺頁”的幾率，知道減少“缺頁”次數(shù)的效果遠(yuǎn)比減少一些代碼量執(zhí)行的效果。另外即使被調(diào)用函數(shù)所在頁面可能也在內(nèi)存中，但是因?yàn)榕c調(diào)用函數(shù)在空間上相隔甚遠(yuǎn)，所以可能會引起“cache miss”，從而降低執(zhí)行速度。因此總的來說，內(nèi)聯(lián)后程序的執(zhí)行時(shí)間會比沒有內(nèi)聯(lián)要少。即程序的速度更快，這也是因?yàn)閮?nèi)聯(lián)后代碼的空間“locality”特性提高了。但正如上面分析空間影響時(shí)提到的，當(dāng)AS遠(yuǎn)大于SS，且n非常大時(shí)，最終程序的大小會比沒有內(nèi)聯(lián)時(shí)要大很多。代碼量大意味著用來存放代碼的內(nèi)存頁也會更多，這樣因?yàn)閳?zhí)行代碼而引起的“缺頁”也會相應(yīng)增多。如果這樣，最終程序的執(zhí)行時(shí)間可能會因?yàn)榇罅康?#8220;缺頁”而變得更多，即程序的速度變慢。這也是為什么很多編譯器對于函數(shù)體代碼很多的函數(shù)，會拒絕對其進(jìn)行內(nèi)聯(lián)的請求。即忽略“inline”關(guān)鍵字，而對如同普通函數(shù)那樣編譯。
綜合上面的分析，在采用內(nèi)聯(lián)時(shí)需要內(nèi)聯(lián)函數(shù)的特征。比如該函數(shù)自己的函數(shù)體代碼量，以及程序執(zhí)行時(shí)可能被調(diào)用的次數(shù)等。當(dāng)然，判斷內(nèi)聯(lián)效果的最終和最有效的方法還是對程序的大小和執(zhí)行時(shí)間進(jìn)行實(shí)際測量，然后根據(jù)測量結(jié)果來決定是否應(yīng)該采用內(nèi)聯(lián)，以及對哪些函數(shù)進(jìn)行內(nèi)聯(lián)。
如下根據(jù)內(nèi)聯(lián)的本質(zhì)來討論與其相關(guān)的一些其他特點(diǎn)。
如前所述，因?yàn)檎{(diào)用內(nèi)聯(lián)函數(shù)的編譯單元必須有內(nèi)聯(lián)函數(shù)的函數(shù)體代碼信息。又因?yàn)镺DR規(guī)則和考慮到代碼的可維護(hù)性，所以一般將內(nèi)聯(lián)函數(shù)的定義放在一個(gè)頭文件中，然后在每個(gè)調(diào)用該內(nèi)聯(lián)函數(shù)的編譯單元中#include該頭文件?，F(xiàn)在考慮這種情況，即在一個(gè)大型程序中，某個(gè)內(nèi)聯(lián)函數(shù)因?yàn)榉浅Ｍㄓ茫淮蠖鄶?shù)編譯單元用到對該內(nèi)聯(lián)函數(shù)的一個(gè)修改，就會引起所有用到它的編譯單元的重新編譯。對于一個(gè)真正的大型程序，重新編譯大部分編譯單元往往意味著大量的編譯時(shí)間。因此內(nèi)聯(lián)最好在開發(fā)的后期引入，以避免可能不必要的大量編譯時(shí)間的浪費(fèi)。
再考慮這種情況，如果某開發(fā)小組在開發(fā)中用到了第三方提供的程序庫，而這些程序庫中包含一些內(nèi)聯(lián)函數(shù)。因?yàn)樵撻_發(fā)小組的代碼中在用到第三方提供的內(nèi)聯(lián)函數(shù)處，都是將該內(nèi)聯(lián)函數(shù)的函數(shù)體代碼拷貝到調(diào)用處，即該開發(fā)小組的代碼中包含了第三方提供代碼的“實(shí)現(xiàn)”。假設(shè)這個(gè)第三方單位在下一個(gè)版本中修改了某些內(nèi)聯(lián)函數(shù)的定義，那么雖然這個(gè)第三方單位并沒有修改任何函數(shù)的對外接口，而只是修改了實(shí)現(xiàn)，該開發(fā)小組要想利用這個(gè)新的版本，仍然需要重新編譯?？紤]到可能該開發(fā)小組的程序已經(jīng)發(fā)布，那么這種重新編譯的成本會相當(dāng)高；相反，如果沒有內(nèi)聯(lián)，并且仍然只是修改實(shí)現(xiàn)，那么該開發(fā)小組不必重新編譯即可利用新的版本。
因?yàn)閮?nèi)聯(lián)的本質(zhì)就是用函數(shù)體代碼代替對該函數(shù)的調(diào)用，所以考慮遞歸函數(shù)，如：
[inline] int foo(int n)
{
...
return foo(n-1);
}
如果編譯器編譯某個(gè)調(diào)用此函數(shù)的編譯單元，如：
void func()
{
...
int m = foo(n);
...
}
考慮如下兩種情況。
（1）如果在編譯該編譯單元且調(diào)用foo時(shí)，提供的參數(shù)n不能知道其實(shí)際值，則編譯器無法知道對foo函數(shù)體進(jìn)行多少次代替。在這種情況下，編譯器會拒絕對foo函數(shù)進(jìn)行內(nèi)聯(lián)。
（2）如果在編譯該編譯單元且調(diào)用foo時(shí)，提供的參數(shù)n能夠知道其實(shí)際值，則編譯器可能會視n值的大小來決定是否對foo函數(shù)進(jìn)行內(nèi)聯(lián)。因?yàn)槿绻鹡很大，內(nèi)聯(lián)展開可能會使最終程序的大小變得很大。
如前所述，因?yàn)閮?nèi)聯(lián)函數(shù)是編譯期行為，而虛擬函數(shù)是執(zhí)行期行為，因此編譯器一般會拒絕對虛擬函數(shù)進(jìn)行內(nèi)聯(lián)的請求。但是事情總有例外，內(nèi)聯(lián)函數(shù)的本質(zhì)是編譯器編譯調(diào)用某函數(shù)時(shí)，將其函數(shù)體代碼代替call調(diào)用，即內(nèi)聯(lián)的條件是編譯器能夠知道該處函數(shù)調(diào)用的函數(shù)體。而虛擬函數(shù)不能夠被內(nèi)聯(lián)，也是因?yàn)樵诰幾g時(shí)一般來說編譯器無法知道該虛擬函數(shù)到底是哪一個(gè)版本，即無法確定其函數(shù)體。但是在兩種情況下，編譯器是能夠知道虛擬函數(shù)調(diào)用的真實(shí)版本的，因此虛擬函數(shù)可以被內(nèi)聯(lián)。
其一是通過對象，而不是指向?qū)ο蟮闹羔樆蛘邔ο蟮囊谜{(diào)用虛擬函數(shù)，這時(shí)編譯器在編譯期就已經(jīng)知道對象的確切類型。因此會直接調(diào)用確定的某虛擬函數(shù)實(shí)現(xiàn)版本，而不會產(chǎn)生“動態(tài)綁定”行為的代碼。
其二是雖然是通過對象指針或者對象引用調(diào)用虛擬函數(shù)，但是編譯時(shí)編譯器能知道該指針或引用對應(yīng)到的對象的確切類型。比如在產(chǎn)生的新對象時(shí)做的指針賦值或引用初始化，發(fā)生在于通過該指針或引用調(diào)用虛擬函數(shù)同一個(gè)編譯單元并且二者之間該指針沒有被改變賦值使其指向到其他不能確切知道類型的對象（因?yàn)橐貌荒苄薷慕壎?，因此無此之虞）。此時(shí)編譯器也不會產(chǎn)生動態(tài)綁定的代碼，而是直接調(diào)用該確定類型的虛擬函數(shù)實(shí)現(xiàn)版本。
在這兩種情況下，編譯器能夠?qū)⒋颂摂M函數(shù)內(nèi)聯(lián)化，如：
inline virtual int x::y (char* a)
{
...
}
void z (char* b)
{
x_base* x_pointer = new x(some_arguments_maybe);
x x_instance(maybe_some_more_arguments);
x_pointer->y(b);
x_instance.y(b);
當(dāng)然在實(shí)際開發(fā)中，通過這兩種方式調(diào)用虛擬函數(shù)時(shí)應(yīng)該非常少，因?yàn)樘摂M函數(shù)的語義是“通過基類指針或引用調(diào)用，到真正運(yùn)行時(shí)才決定調(diào)用哪個(gè)版本”。
從上面的分析中已經(jīng)看到，編譯器并不總是尊重“inline”關(guān)鍵字。即使某個(gè)函數(shù)用“inline”關(guān)鍵字修飾，并不能夠保證該函數(shù)在編譯時(shí)真正被內(nèi)聯(lián)處理。因此與register關(guān)鍵字性質(zhì)類似，inline僅僅是給編譯器的一個(gè)“建議”，編譯器完全可以視實(shí)際情況而忽略之。
另外從內(nèi)聯(lián)，即用函數(shù)體代碼替代對該函數(shù)的調(diào)用這一本質(zhì)看，它與C語言中的函數(shù)宏（macro）極其相似，但是它們之間也有本質(zhì)的區(qū)別。即內(nèi)聯(lián)是編譯期行為，宏是預(yù)處理期行為，其替代展開由預(yù)處理器來做。也就是說編譯器看不到宏，更不可能處理宏。另外宏的參數(shù)在其宏體內(nèi)出現(xiàn)兩次或兩次以上時(shí)經(jīng)常會產(chǎn)生副作用，尤其是當(dāng)在宏體內(nèi)對參數(shù)進(jìn)行++或--操作時(shí)，而內(nèi)聯(lián)不會。還有，預(yù)處理器不會也不能對宏的參數(shù)進(jìn)行類型檢查。而內(nèi)聯(lián)因?yàn)槭蔷幾g器處理的，因此會對內(nèi)聯(lián)函數(shù)的參數(shù)進(jìn)行類型檢查，這對于寫出正確且魯棒的程序，是一個(gè)很大的優(yōu)勢。最后，宏肯定會被展開，而用inline關(guān)鍵字修飾的函數(shù)不一定會被內(nèi)聯(lián)展開。
最后順帶提及，一個(gè)程序的惟一入口main()函數(shù)肯定不會被內(nèi)聯(lián)化。另外，編譯器合成的默認(rèn)構(gòu)造函數(shù)、拷貝構(gòu)造函數(shù)、析構(gòu)函數(shù)，以及賦值運(yùn)算符一般都會被內(nèi)聯(lián)化
