第30條： 深入探究內(nèi)聯(lián)函數(shù)
內(nèi)聯(lián)函數(shù)——多么振奮人心的一項(xiàng)發(fā)明！它們看上去與函數(shù)很相像，它們擁有與函數(shù)類似的行為，它們要比宏（參見第 2 條）好用的多，同時你在調(diào)用它們時帶來的開銷比一般函數(shù)小得多。可謂“內(nèi)聯(lián)在手，別無他求。”
你得到的遠(yuǎn)遠(yuǎn)比你想象的要多，因?yàn)楣?jié)約函數(shù)調(diào)用的開銷僅僅是冰山一角。編譯器優(yōu)化通常是針對那些沒有函數(shù)調(diào)用的代碼，因此當(dāng)你編寫內(nèi)聯(lián)函數(shù)時，編譯器就會針對函數(shù)體的上下文進(jìn)行優(yōu)化工作。然而大多數(shù)編譯器都不會針對“外聯(lián)”函數(shù)調(diào)用進(jìn)行優(yōu)化。
然而，在你的編程生涯中，“沒有免費(fèi)的午餐”這句生活哲言同樣奏效，內(nèi)聯(lián)函數(shù)不會幸免。內(nèi)聯(lián)函數(shù)背后蘊(yùn)含的理念是：用代碼本體來取代每次函數(shù)調(diào)用，這樣做很可能會是目標(biāo)代碼的體積增大不少，這一點(diǎn)并不是非要統(tǒng)計學(xué)博士才能看得清。對于內(nèi)存空間有限的機(jī)器而言，過分熱衷于使用內(nèi)聯(lián)則會造成函數(shù)占用過多的空間。即使在虛擬內(nèi)存中，那些冗余的內(nèi)聯(lián)代碼也會帶來不少無謂的分頁，從而使緩存讀取命中率降低，最終帶來性能的犧牲。
另一方面，如果一個內(nèi)聯(lián)函數(shù)體非常的短，那么為函數(shù)體所生成代碼的體積就會比為函數(shù)調(diào)用生成的代碼小一些。此時，內(nèi)聯(lián)函數(shù)才真正做到了減小目標(biāo)代碼和提高緩存讀取命中率的目的。
我們要時刻保持清醒， Inline 是對編譯器的一次請求，而不是一條命令。這種請求可以顯式提出也可以隱式提出。隱式請求的途徑就是：在類定義的內(nèi)部定義函數(shù)：
class Person {
public:
...
int age() const { return theAge; }// 隱式內(nèi)聯(lián)請求 :
... // 年齡 age 在類定義中做出定義
private:
int theAge;
};
這樣的函數(shù)通常是成員函數(shù)，但是類中定義的函數(shù)也可以是友元（參見第 46 條），如果函數(shù)是友元，那么也應(yīng)隱式將它們定義為內(nèi)聯(lián)函數(shù)。
顯式聲明內(nèi)聯(lián)函數(shù)的方法為：在函數(shù)定義之前添加 inline 關(guān)鍵字。比如說，下面是標(biāo)準(zhǔn) max 模板（來自 <algorithm> ）通常的定義方式：
template<typename T> // 顯式內(nèi)聯(lián)請求：
inline const T& std::max(const T& a, const T& b)
{ return a < b ? b : a; } // 在 std::max 的前邊添加 ”inline”
max 是一個模板這一事實(shí)，讓我們不免得出這樣的推論：內(nèi)聯(lián)函數(shù)和模 板都應(yīng)該在頭文件中定義。這就使一些程序員做出“函數(shù)模板必須為內(nèi)聯(lián)函數(shù)”的論斷。這一結(jié)論不僅不合法，而且也存在潛在的害處，所以這里我們還是要大略的了解一下。
由于大多數(shù)構(gòu)建環(huán)境都是在編譯過程中進(jìn)行內(nèi)聯(lián)，因此內(nèi)聯(lián)函數(shù)一般情況下都應(yīng)該定義在頭文件中。編譯器必須首先了解函數(shù)的大致情況，以便于用所調(diào)用函數(shù)體來代替這次函數(shù)調(diào)用。（一些構(gòu)建環(huán)境在連接過程中進(jìn)行內(nèi)聯(lián)，還有個別基于 .NET 通用語言基礎(chǔ)結(jié)構(gòu)（ CLI ）的托管環(huán)境甚至是在運(yùn)行時進(jìn)行內(nèi)聯(lián)。這樣的環(huán)境僅僅屬于例外，而不是守則。在大多數(shù) C++ 程序中，內(nèi)聯(lián)是一個編譯時行為。）
模板通常保存在頭文件中，但是編譯器還需要了解模板的大致情形，以便于在用到時進(jìn)行正確的實(shí)例化。（然而，這并不是一成不變的。一些構(gòu)建環(huán)境在連接時進(jìn)行模板實(shí)例化。但是編譯時實(shí)例化才是更通用的方式。）
模板實(shí)例化相對于內(nèi)聯(lián)是獨(dú)立的。如果你正在編寫一個模板，而你又確信由這個模板所實(shí)例化出的所有函數(shù)都應(yīng)該是內(nèi)聯(lián)的，那么這個模板就應(yīng)該添 加 inline 關(guān)鍵字；這也就是上文中 std::max 實(shí) 現(xiàn)的做法。但是如果你正在編寫的模板并不需要實(shí)例化內(nèi)聯(lián)函數(shù)，那么就不需要聲明內(nèi)聯(lián)模板（無論是顯式還是隱式）。內(nèi)聯(lián)也是有開銷的，不假思索就引入內(nèi)聯(lián)的開銷的做法并不明智。我們已經(jīng)介紹過了內(nèi)聯(lián)是如何使代碼膨脹起來的（對于模板的作者而言，還應(yīng)該做更周密的考慮——參見第 44 條），但是內(nèi)聯(lián)還會帶來其他的開銷，這就是下文中我們將要討論的問題。
inline 是對編譯器的一次請求，但編譯器可能會忽略它。在我們的討論開 始之前，我們首先要弄清這一點(diǎn)。大多數(shù)編譯器如果認(rèn)為當(dāng)前的函數(shù)過于復(fù)雜（比如包括循環(huán)或遞歸的函數(shù)），或者這個函數(shù)是虛函數(shù)（即使是最平常的虛函數(shù)調(diào)用），就會拒絕將其內(nèi)聯(lián)。后一個結(jié)論很好理解。因?yàn)?/span> virtual 意味著“等到運(yùn)行時再指出要調(diào)用哪個程序，”而 inline 意味著“在執(zhí)行程序之前，使用要調(diào)用的函數(shù)來代替這次調(diào)用。”如果編譯器不知道要調(diào)用哪個函數(shù)，那么它們拒絕內(nèi)聯(lián)函數(shù)體的做法就無可厚非了。
綜上所述，我們得出下面的結(jié)論：一個給定的函數(shù)是否得到內(nèi)聯(lián)，取決于你正在使用的構(gòu)建環(huán)境——主要是編譯器。幸運(yùn)的是，大多數(shù)編譯器擁有診斷機(jī)制，如果編譯器在內(nèi)聯(lián)函數(shù)時失敗了，那么它們將會做出警告（參見第 53 條）。
有些時候，即使編譯器認(rèn)為某個函數(shù)非常適合進(jìn)行內(nèi)聯(lián)，可是還是會為它提供一個函數(shù)體。舉例說，如果你的程序要取得某個內(nèi)聯(lián)函數(shù)的地址，那么編譯器必須用典型的方法為其創(chuàng)建一個外聯(lián)的函數(shù)體。那么編譯器又怎樣讓一個指針去指向一個不存在的函數(shù)呢？再加上編譯器一般不會通過對函數(shù)指針的調(diào)用進(jìn)行內(nèi)聯(lián)這一事實(shí)，更能肯定這一結(jié)論：對于一個內(nèi)聯(lián)函數(shù)的調(diào)用是否應(yīng)該得到內(nèi)聯(lián)，取決于這一調(diào)用是如何進(jìn)行的：
inline void f() {...} // 假設(shè)編譯器樂意于將 f 的調(diào)用進(jìn)行內(nèi)聯(lián)
void (*pf)() = f; // pf 指向 f
...
f(); // 此調(diào)用將被內(nèi)聯(lián)，因?yàn)檫@是一次“正常”的調(diào)用
pf(); // 此調(diào)用很可能不會被內(nèi)聯(lián)，
// 因?yàn)樗峭ㄟ^一個函數(shù)指針進(jìn)行的
即使你從未使用函數(shù)指針，未得到內(nèi)聯(lián)的函數(shù)依然“陰魂不散”，這是因?yàn)樾枨蠛瘮?shù)指針的不僅僅是程序員。比如，編譯器在為對象的數(shù)組進(jìn)行構(gòu)造或析構(gòu)時，也會生成構(gòu)造函數(shù)和析構(gòu)函數(shù)的外聯(lián)副本，從而使它們可以得到這些函數(shù)的指針以便使用。
實(shí)際上，為構(gòu)造函數(shù)和析構(gòu)函數(shù)進(jìn)行內(nèi)聯(lián)通常不是一個好的選擇，這兩者甚至不如一些隨意挑選的“選手”。請看下面示例 中 Derived 類的構(gòu) 造函數(shù)：
class Base {
public:
...
private:
std::string bm1, bm2; // 基類成員 1 和 2
};
class Derived: public Base {
public:
Derived() {} // 派生類的構(gòu)造函數(shù)為空 — 還有別的可能 ?
...
private:
std::string dm1, dm2, dm3;// 派生類成員 1–3
};
乍看上去，將這個構(gòu)造函數(shù)進(jìn)行內(nèi)聯(lián)再適合不過了，因?yàn)樗话魏未a。其實(shí)你的眼睛欺騙了你。
C++ 對于在創(chuàng)建和銷毀對象的過程中發(fā)生的事件進(jìn)行了多方面的保證。比如，當(dāng)你使用 new 時，你動態(tài)創(chuàng)建的對象的構(gòu)造函數(shù)就會自動將其初始化；當(dāng)你使用 delete 時，將調(diào)用相關(guān)的析構(gòu)函數(shù)。當(dāng)你創(chuàng)建一個對象時。每個基類和該對象中的每個數(shù)據(jù)成員將自動得到構(gòu)造，在銷毀這個對象時，針對兩者的析構(gòu)過程將會自動進(jìn)行。如果在對象的構(gòu)造過程中有異常拋出，那么對象中已經(jīng)得到構(gòu)造的部分將統(tǒng)統(tǒng)被自動銷毀。在所有這些場景中， C++ 告訴你什么一定會發(fā)生，但它沒有說明如何發(fā)生。這一點(diǎn)取決于編譯器的實(shí)現(xiàn)者，但是必須要清楚的一點(diǎn)是，這些事情并不是自發(fā)的。你必須要在程序中添加一些代碼來實(shí)現(xiàn)它們。這些代碼一定存在于某處，它們由編譯器代勞，用于在編譯過程中插入你的程序中。一些時候它們就存在于構(gòu)造函數(shù)和析構(gòu)函數(shù)中，所以，對于上文中 Derived 的空構(gòu)造函數(shù)，我們可以將具體實(shí)現(xiàn)中生成的代碼等價看作：
Derived::Derived() // Derived 空構(gòu)造函數(shù)的抽象實(shí)現(xiàn)
{
Base::Base(); // 初始化 Base 部分
try { dm1.std::string::string(); } // 嘗試構(gòu)造 dm1
catch (...) { // 如果拋出異常 ,
Base::~Base(); // 銷毀基類部分 ,
throw; // 并且傳播該異常
}
try { dm2.std::string::string(); } // 嘗試構(gòu)造 dm2
catch(...) { // 如果拋出異常 ,
dm1.std::string::~string(); // 銷毀 dm1,
Base::~Base(); // 銷毀基類部分 ,
throw; // 并且傳播該異常
}
try { dm3.std::string::string(); } // 嘗試構(gòu)造 dm3
catch(...) { // 如果拋出異常 ,
dm2.std::string::~string(); // 銷毀 dm2,
dm1.std::string::~string(); // 銷毀 dm1,
Base::~Base(); // 銷毀基類部分 ,
throw; // 并且傳播該異常
}
}
這段代碼并不能完全真實(shí)反映出編譯器所做的事情，因?yàn)檎鎸?shí)的編譯器采用的做法更加復(fù)雜。然而，上面的代碼可以較為精確地反映出 Derived 的“空”構(gòu)造函數(shù)必須要提供的內(nèi)容。無論編譯器處理異常的實(shí)現(xiàn)方式多么復(fù)雜， Derived 的構(gòu)造函數(shù)必須至少為其數(shù)據(jù)成員和基類調(diào)用構(gòu)造函數(shù)，這些調(diào)用（可能就是內(nèi)聯(lián)的）會使 Derived 顯得不那么適合進(jìn)行內(nèi)聯(lián)。
這 一推理過程對于 Base 的構(gòu)造函數(shù)同樣適用，因此如果將 Base 內(nèi)聯(lián)，所有添加進(jìn)其中的代碼同樣也會添加進(jìn) Derived 的構(gòu)造函數(shù)中（通過 Derived 構(gòu)造函數(shù)調(diào)用 Base 構(gòu)造函數(shù)的過程）。同時，如果 string 的構(gòu)造函數(shù)恰巧被內(nèi)聯(lián)了，那么 Derived 的構(gòu)造函數(shù)將為其復(fù)制出五份副本，分別對應(yīng) Derived 對象中包含的五個字符串（兩個繼承而來，另外三個系對象本身包括）。現(xiàn)在，“ Derived 的構(gòu)造函數(shù)是否應(yīng)該內(nèi)聯(lián)不是一個純機(jī)械化問題”就很容易理解了。對于 Derived 的析構(gòu)函數(shù)也一樣，你必須親自關(guān)注 Derived 的構(gòu)造函數(shù)初始化的對象是否全部恰當(dāng)?shù)牡玫戒N毀，這一點(diǎn)機(jī)器無法代替。
庫設(shè)計者必須估算出將函數(shù)內(nèi)聯(lián)所帶來的影響，因?yàn)槟愀緹o法為庫中客戶端程序員可見的內(nèi)聯(lián)函數(shù)提供底層的升級。換句話說，如果 f 是庫中的一個內(nèi)聯(lián)函數(shù)，那么庫的客戶端程序員就會將 f 的函數(shù)體編譯進(jìn)他們的程序中。隨后，如果一個庫實(shí)現(xiàn)者修改了 f 的內(nèi)容，那么所有曾經(jīng)使用過 f 的客戶端程序員必須要重新編譯他們的代碼。這一點(diǎn)是我們所不希望看到的。另一個角度講，如果 f 不是內(nèi)聯(lián)函數(shù)，那么修改 f 只需要客戶端程序員重新連接一下就可以了。這樣要比重新編譯減少很多繁雜的工作，并且，如果庫中需要使用的函數(shù)是動態(tài)鏈接的，那么它對于客戶端程序員就是完全透明的。
我們的目標(biāo)是開發(fā)優(yōu)質(zhì)的程序，因此要將這些重要問題牢記在心。但是以編寫代碼實(shí)際操作的角度來說，這一個事實(shí)將淹沒一切：大多數(shù)調(diào)試人員面對內(nèi)聯(lián)函數(shù)時會遇到麻煩。這并不會令人意外，因?yàn)槟銦o法為一個尚不存在的函數(shù)設(shè)定一個跟蹤點(diǎn)。一些構(gòu)建環(huán)境試圖支持內(nèi)聯(lián)函數(shù)的調(diào)試，但是幾乎都失敗了，大多數(shù)環(huán)境都是在調(diào)試過程中直接禁止內(nèi)聯(lián)。
對于“哪個函數(shù)應(yīng)該聲明為 inline 而哪些不應(yīng)該”這一問題，我們可以由上文中引出一個邏輯上的策略。起初，不要內(nèi)聯(lián)任何內(nèi)容，或者僅挑選出那些不得不內(nèi)聯(lián)的函數(shù)（參見第 46 條）或者那些確實(shí)是很細(xì)小的程序（比如本節(jié)開篇處出現(xiàn)的 Person::age ）進(jìn)行內(nèi)聯(lián)。謹(jǐn)慎引入內(nèi)聯(lián)，你就為調(diào)試工作提供了方便，但是你仍然要為內(nèi)聯(lián)擺正位置：它屬于手工的優(yōu)化操作。不要忘記 80-20 經(jīng)驗(yàn)決定主義原則：一個典型的程序?qū)⒒ㄈ?/span> 80% 的時間僅僅運(yùn)行 20% 的代碼。這是一個非常重要的原則，因?yàn)樗鼤r時刻刻提醒我們，軟件開發(fā)者的目標(biāo)是：找出你的代碼中 20% 的這部分進(jìn)行優(yōu)化，從而從整體上提高程序的性能。你可以花費(fèi)很長的時間進(jìn)行內(nèi)聯(lián)、修改函數(shù)等等，但如果你沒有鎖定正確的目標(biāo)，那么你做再多的努力也是徒勞。
銘記在心
l 僅僅對小型的、調(diào)用頻率高的程序進(jìn)行內(nèi)聯(lián)。這將簡化你的調(diào)試操作，為底層更新提供方便，降低潛在的代碼膨脹發(fā)生的可能，并且可以讓程序獲得更高的速度。
l 不要將模板聲明為 inline 的，因?yàn)樗鼈円话阍陬^文件中出現(xiàn)。