30 透徹了解inlining 的裡裡外外

1、inline方法相當於文字替換，不需要承擔方法呼叫的額外開銷，同時還有潛在的優勢，文字替換後，編譯器會進行**優化。而對於方法呼叫，編譯器沒有能力進行**優化。

2、顯而易見，inline方法往往會導致目標**膨脹變大。但是，對於方法本體很小的情況，可能會出現，替換後的文字比方法呼叫的**還要小。這也意味著，一般情況下，只有方法本體比較小的情況，才應該宣告為inline。

3、特別注意：inline只是乙個申請，而不是命令。同時，對於class定義中的方法實現，也暗示著申請inline。申請inline告訴編譯器，進行文字替換，但最終能不能文字替換，還要取決於編譯器。

4、編譯器拒絕對業務複雜（包含迴圈和遞迴）的方法inlining，同時拒絕對virtual方法執行inlining，為啥？

virtual方法是執行時確定呼叫哪個方法，而inline是編譯時文字替換，二者矛盾。

5、當取inline方法位址的時候，也不進行文字替換，為啥？

這種情況是取位址，進行文字替換沒有意義。

6、構造方法和析構方法不應該是inline，為啥？

c++對於「物件被建立和被銷毀時發生什麼事」做個保證。比如：構造過程出現異常，c++保證構造好的那一部分自動銷毀。這就意味著，為了滿足這種保證，c++在構造方法中，增加了一些**。如果將構造方法宣告為inline，意味著文字替換，這就妨礙編譯器新增一些**。

7、考慮下面的情況，其他程式集使用乙個方法，這個方法做了修改。如果這個方法是inline，意味著外部程式集必須重新編譯，重新進行文字替換。而如果不是inline，外部程式集不需要重新編譯。

8、顯然，inline方法不能很好地支援除錯。有些偵錯程式勉強支援除錯，為了支援除錯inline，大多數偵錯程式的做法是：在除錯版本禁止inlining。

9、正確的做法是：一開始不要宣告為inline，在後期找到效率的瓶頸所在，如果是方法呼叫導致的原因，再進行inline。