inline 函數(shù)——多么棒的主意啊！它們看起來像函數(shù)，它們產(chǎn)生的效果也像函數(shù)，它們在各方面都比宏好得太多太多，而你卻可以在調(diào)用它們時不招致函數(shù)調(diào)用的成本。你還有什么更多的要求呢？
    實際上你得到的可能比你想的更多，因為避免函數(shù)調(diào)用的成本只是故事的一部分。在典型情況下，編譯器的優(yōu)化是為了一段連續(xù)的沒有函數(shù)調(diào)用的代碼設(shè)計的，所以當你 inline 化一個函數(shù)，你可能就使得編譯器能夠?qū)瘮?shù)體實行上下文相關(guān)的特殊優(yōu)化。大多數(shù)編譯器都不會對 "outlined" 函數(shù)調(diào)用實行這樣的優(yōu)化。
    然而，在編程中，就像在生活中，沒有免費午餐，而 inline 函數(shù)也不例外。一個 inline 函數(shù)背后的思想是用函數(shù)本體代替每一處對這個函數(shù)的調(diào)用，而且不必拿著統(tǒng)計表中的 Ph.D. 就可以看出這樣可能會增加你的目標代碼的大小。在有限內(nèi)存的機器上，過分熱衷于 inline 化會使得程序?qū)τ诳捎每臻g來說過于龐大。即使使用了虛擬內(nèi)存，inline 引起的代碼膨脹也會導致附加的分頁調(diào)度，減少指令緩存命中率，以及隨之而來的性能損失。
    在另一方面，如果一個 inline 函數(shù)本體很短，為函數(shù)本體生成的代碼可能比為一個函數(shù)調(diào)用生成的代碼還要小。如果是這種情況，inline 化這個函數(shù)可以實際上導致更小的目標代碼和更高的指令緩存命中率！ 記住，inline 是向編譯器發(fā)出的一個請求，而不是一個命令。這個請求能夠以顯式的或隱式的方式提出。隱式的方法就是在一個類定義的內(nèi)部定義一個函數(shù)：
    class Person {
    public:
    ...
    int age() const { return theAge; } // an implicit inline request: age is
    ... // defined in a class definition
    private:
    int theAge;
    };
    這樣的函數(shù)通常是成員函數(shù)，不過我們知道友元函數(shù)也能被定義在類的內(nèi)部，如果它們在那里，它們也被隱式地聲明為 inline。
    顯式的聲明一個 inline 函數(shù)的方法是在它的聲明之前加上 inline 關(guān)鍵字。例如，以下就是標準 max 模板（來自 ）經(jīng)常用到的的實現(xiàn)方法：
    template // an explicit inline
    inline const T& std::max(const T& a, const T& b) // request: std::max is
    { return a < b ? b : a; } // preceded by "inline"
    max 是一個模板的事實引出一個觀察結(jié)論：inline 函數(shù)和模板一般都是定義在頭文件中的。這就使得一些程序員得出結(jié)論斷定函數(shù)模板必須是 inline。這個結(jié)論是非法的而且有潛在的危害，所以它值得我們考察一下。 inline 函數(shù)一般必須在頭文件內(nèi)，因為大多數(shù)構(gòu)建環(huán)境在編譯期間進行 inline 化。為了用被調(diào)用函數(shù)的函數(shù)本體替換一個函數(shù)調(diào)用，編譯器必須知道函數(shù)看起來像什么樣子。（有一些構(gòu)建環(huán)境可以在連接期間進行 inline 化，還有少數(shù)幾個——比如，基于 .NET Common Language Infrastructure (CLI) 的控制環(huán)境——居然能在運行時 inline 化。然而，這些環(huán)境都是例外，并非規(guī)則。inline 化在大多數(shù) C 程序中是一個編譯時行為。）
    模板一般在頭文件內(nèi)，因為編譯器需要知道一個模板看起來像什么以便用到它時對它進行實例化。（同樣，也不是全部如此。一些構(gòu)建環(huán)境可以在連接期間進行模板實例化。然而，編譯期實例化更為普遍。） 模板實例化與 inline 化無關(guān)。如果你寫了一個模板，而且你認為所有從這個模板實例化出來的函數(shù)都應該是 inline 的，那么就聲明這個模板為 inline，這就是上面的 std::max 的實現(xiàn)被做的事情。但是如果你為沒有理由要 inline 化的函數(shù)寫了一個模板，就要避免聲明這個模板為 inline（無論顯式的還是隱式的）。inline 化是有成本的，而且你不希望在毫無預見的情況下遭遇它們。我們已經(jīng)說到 inline 化是如何引起代碼膨脹的，但是，還有其它的成本，過一會兒我們再討論。
    在做這件事之前，我們先來完成對這個結(jié)論的考察：inline 是一個編譯器可能忽略的請求。大多數(shù)編譯器拒絕它們認為太復雜的 inline 函數(shù)（例如，那些包含循環(huán)或者遞歸的），而且，除了最細碎的以外的全部虛擬函數(shù)的調(diào)用都不會被 inline 化。不應該對這后一個結(jié)論感到驚訝。虛擬意味著“等待，直到運行時才能斷定哪一個函數(shù)被調(diào)用”，而 inline 意味著“執(zhí)行之前，用被調(diào)用函數(shù)取代調(diào)用的地方”。如果編譯器不知道哪一個函數(shù)將被調(diào)用，你很難責備它們拒絕 inline 化這個函數(shù)本體。
    所有這些加在一起，得出：一個被指定的 inline 函數(shù)是否能真的被 inline 化，取決于你所使用的構(gòu)建環(huán)境——主要是編譯器。幸運的是，大多數(shù)編譯器都有一個診斷層次，在它們不能 inline 化一個你提出的函數(shù)時，會導致一個警告。