在c/c++中，為了解決一些頻繁呼叫的小函式大量消耗棧空間（棧記憶體）的問題，特別的引入了inline修飾符，表示為內聯函式，棧空間就是指放置程式的區域性資料（也就是函式內資料）的記憶體空間。在系統下，棧空間是有限的，假如頻繁大量的使用就會造成因棧空間不足而導致程式出錯的問題，如，函式的死迴圈遞迴呼叫的最終結果就是導致棧記憶體空間枯竭。
下面我們來看乙個例子：
#include
#include
// 函式定義為inline即:內聯函式
inline char* inline_test(int num)
int main()
return 0;
}上面的例子就是標準的內聯函式的用法，使用inline修飾帶來的好處我們表面看不出來，其實www.cppcns.com，在內部的工作就是在每個for迴圈的內部任何呼叫dbtest(i)的地方都換成了(i%2>0)?」奇」:」偶」，這樣就避免了頻繁呼叫函式對棧記憶體重複開闢所帶來的消耗。
是否內聯 可以在編碼、編譯、連線、甚至是應用程式的安裝進行的。
非執行期,反彙編看看有沒有相關的函式呼叫call沒有就是inline了。
inline的使用是有所限制的，inline只適合涵數體內**簡單的涵數使用，
(1) 不能包含複雜的結構控制語句例如while、switch，並且不能內聯函式本身不能是直接遞迴函式（即，自己內部還呼叫自己的函式）。
(2) 而所有（除了最平凡，幾乎什麼也沒做）的虛函式，都追阻止inlining的進行。
這應該不會引起太多的驚訝，因為virtual意味著」等待，直到執行時期再確定應該呼叫哪乙個函式「，
而inline卻意味著」在編譯階段，將呼叫動作以被呼叫函式的主體取代之「。
如果編譯器做決定時，尚不知道該呼叫哪乙個函式，你就很難責成他們做出乙個inline函式。
inline函式僅僅是乙個對編譯器的建議，所以最後能否真正內聯，看編譯器的意思，
它如果認為函式不複雜，能在呼叫點展開，就會真正內聯，並不是說宣告了內聯就會內聯，宣告內聯只是乙個建議而已。
幸運的是大多數編譯器提供了乙個診斷級別：如果它們無法將你要求的函式 inline 化, 會給你乙個警告資訊。
(1) inline函式的定義放在標頭檔案中
inline 在大多數 c++ 程式中是編譯行為。其次，因為內聯函式要在呼叫點展開，所以編譯器必須隨處可見內聯函式的定義，要不然就成了非內聯函式的呼叫了。所以，這要求每個呼叫了內聯函式的檔案都出現了該內聯函式的定義。因此，將內聯函式的定義放在標頭檔案裡實現是合適的，省卻你為每個檔案實現一次的麻煩。
(2) 宣告跟定義要一致
如果在每個檔案裡都實現一次該內聯函式的話，那麼，最好保證每個定義都是一樣的，否則，將會引起未定義的行為。如果不是每個檔案裡的定義都一樣，那麼，編譯器展開的是哪乙個，那要看具體的編譯器而定。所以，最好將內聯函式定義放在標頭檔案中。
(3) 建構函式和析構函式往往是 inlining 的糟糕候選人
因為建構函式和析構函式編譯器往往做了各式各樣的保證。當你建立物件, 每乙個基類和成員都會自動構造, 當你釋放物件, 每個基類和成員都要自動釋放。
類 inline 函式有兩種方法：
(1) 隱喻式：定義在類中的成員函式預設都是內聯的，如果在類定義時就在類內給出函式定義，那當然最好。
(2) 明確宣告：如果在類中未給出成員函式定義，而又想內聯該函式的話，那在類外要加上inline，否則就認為不是內聯的。
例如，class a
// 自動地成為內聯函式
}將成員函式的定義體放在類宣告之中雖然能帶來書寫上的方便，但不是一種良好的程式設計風格，上例應該改成：
// 標頭檔案
class a
// 定義檔案
inline void a::foo(int x, int y){}
關鍵字inli程式設計客棧ne 必須與函式定義體放在一起才能使函式成為內聯，僅將inline 放在函式宣告前面不起任何作用。
如下風格的函式foo 不能成為內聯函式：
inline void foo(int x, iteicjnnt y); // inline 僅與函式宣告放在一起
void foo(int x, int y){}
而如下風格的函式foo 則成為內聯函式：
void foo(int x, int y);
inline void foo(int x, int y) {} // inline 與函式定義體放在一起
所以說，inline 是一種「用於實現的關鍵字」，而不是一種「用於宣告的關鍵字」。一般地，使用者可以閱讀函式的宣告，但是看不到函式的定義。儘管在大多數教科書中內聯函式的宣告、定義體前面都加了inline 關鍵字，但我認為inline不應該出現在函式的宣告中。這個細節雖然不會影響函式的功能，但是體現了高質量c++/c 程式設計風格的乙個基本原則：宣告與定義不可混為一談，使用者沒有必要、也不應該知道函式是否需要內聯。
內聯能提高函式的執行效率，為什麼不把所有的函式都定義成內聯函式？如果所有的函式都是內聯函式，還用得著「內聯」這個關鍵字嗎？
內聯是以**膨脹（複製）為代價，僅僅省去了函式呼叫的開銷，從而提高函式的執行效率。 如果執行函式體內**的時間，相比於函式呼叫的開銷較大，那麼效率的收穫會很少。另一方面，每一處內聯函式的呼叫都要複製**，將使程式的總**量增大，消耗更多的記憶體空間。
以下情況不宜使用內聯：
(1) 如果函式體內的**比較長，使用內聯將導致記憶體消耗代價較高。
(2) 如果函式體內出現迴圈，那麼執行函式體內**的時間要比函式呼叫的開銷大。
(3) 類的建構函式和析構函式容易讓人誤解成使用內聯更有效。要當心建構函式和析構函式可能會隱藏一些行為，如「偷偷地」執行了基類或成員物件的建構函式和析構函式。所以不要隨便地將建構函式和析構函式的定義體放teicjn在類宣告中。
乙個好的編譯器將會根據函式的定義體，自動地取消不值得的內聯（這進一步說明了 inline 不應該出現在函式的宣告中）。
內聯函式並不是乙個增強效能的靈丹妙藥。只有當函式非常短小的時候它才能得到我們想要的效果；但是，如果函式並不是很短而且在很多地方都被呼叫的話，那麼將會使得可執行體的體積增大。 最令人煩惱的還是當編譯器拒絕內聯的時候。在老的實現中，結果很不盡人意，雖然在新的實現中有很大的改善，但是仍然還是不那麼完善的。一些編譯器能夠足夠的聰明來指出哪些函式可以內聯哪些不能，但是大多數編譯器就不那麼聰明了，因此這就需要我們的經驗來判斷。如果內聯函式不能增強效能，就避免使用它！
C odr用法案例詳解
the main module.file odr test1.cpp include void module1 print declaration of an exeternal function inline int f1 class a const double c 4.2 constexpr ...
MFC LoadImage用法案例詳解
目錄 handle loadimage hinstance hinst,若引導程式外部資源傳null,否則一般傳afxgetinstancehandle lpctstr lpszname,名稱或全路徑 uint utype,型別 image bitmap或image icon或image curso...
C pictureBox用法案例詳解
picturebox 控制項可以顯示來自位圖 圖示或者元檔案，以及來自增強的元檔案 jpeg 或 gif 檔案的圖形。如果控制項不足以顯示整幅圖象，則裁剪圖象以適應控制項的大小。展示了控制項的sizemode四種格式 最好的應該是zoom，在不發生形變的條件下，對進行縮放。sizemode auto...