[原創文章歡迎轉載，但請保留作者信息]
Justin 于 2010-01-04
使用內聯函數(inline function)可以省去一般函數調用的入棧操作開銷，比宏(macro)要好用。從編譯器的角度來看，沒有函數調用的代碼要更容易優化。
但是天下沒有免費的午餐，以空間換時間的內聯函數同時也帶來了更大的程序占用空間，更甚者還會因為這變大的代碼空間導致額外的內存換頁操作，降低指令緩存(instruction cache)的命中率……這些都是使用內聯函數需要考慮到的負面影響。(Scott還是辯證地提醒了一點：當內聯函數非常短小時，相比一般意義上的函數調用，它能夠幫助編譯器生成更小的最終代碼和運行時更高的指令緩存命中率)
內聯函數的聲明可以是顯式的：使用inline關鍵字；也可以是隱式的：在類的定義中定義函數。
內聯函數一般而言都是定義在頭文件中，這是因為大多數編譯器的內聯動作都是發生在編譯過程中。(也有著鏈接甚至是運行中才進行內聯的，但是俺們這里隨大流，講主要矛盾)
雖然內聯函數和函數模板有一點相似：它們都幾乎定義在頭文件中，但是這兩者之間沒有必然聯系，而非有的程序員想的那樣“函數模板一定是內聯的”)
另外一點容易被初學者忽視的是，內聯函數的定義僅僅是對編譯器提出內聯的請求。編譯器完全有可能忽視這個請求，于是某“內聯函數”有可能在最后還是生成了一般函數的代碼。在這個情況下編譯器很有可能是對的：
-
請求內聯的函數有可能太過于復雜
-
請求內聯的函數有可能是虛函數(虛函數的真正實體要在運行時才能得知，讓編譯器編譯階段去做內聯實在有點強人所難)
-
請求內聯的函數沒什么問題，但是在代碼中有用函數指針的方式調用該函數(這樣編譯器也沒辦法，如果不生成一般函數哪來的函數指針？)
這些情況下確實不應該把函數作為內聯函數。一個“內聯函數”是否最終生成了內聯函數，還得編譯器說了算。
然而編譯器并不是總能幫助我們做出正確的決定，還有一些情況是需要我們自己做出判斷的：
-
請求內聯的函數是構造/析構函數(表面上看起來某個構造/析構函數很短小甚至是空的，但是為了構造/析構類中的其他成員，編譯器有可能會“自覺”地寫入必要的代碼，這樣的構造/析構函數就有可能不適合再做內聯了)這一點原文中有更詳細的說明。
-
當編寫支持庫時(library)也不建議使用內聯函數，因為一旦用戶使用了這些含有內聯函數的庫并編譯了自己的程序，這些內聯函數就已經“寫死”在他們的程序中了。當日后對原先的庫做了更新修改，用戶就必須重新編譯整個程序才能用上新的補丁。而一般的函數就不會有這個問題：他們是動態鏈接的，用戶根本感覺不到任何改動。
-
考慮到很多調試器(debugger)無法調試內聯函數(本來就沒有這么一個“函數”，叫人家怎么設斷點？)，在調試版本中也不建議使用內聯函數。
有那么多需要注意的地方，大師最后總結了一下：用好內聯函數的第一步就是：不用內聯函數。并沒有那么多的函數真正需要內聯，因為80%的程序運行時間都是花在了20%的代碼中。第二步是把內聯函數當成是手工優化的手段，僅僅在非常需要效率和優化的代碼中使用內聯。
|