inline 函數看似完美：像函數、行為像函數、優於巨集、避免呼叫開銷。但現實遠比想像複雜——沒有免費午餐。
inline 的雙面效應
正面：啟用編譯器深度優化
- 消除呼叫開銷（參數壓棧、跳轉、返回）
- 使編譯器能對函數本體進行上下文相關優化：常數摺疊、循環展開、指令排程、死碼消除等
- 極短函數可能比呼叫指令更小，反而減少目標碼大小、提高指令快取命中率
負面：程式碼膨脹風險
- 每處呼叫點展開函數本體，大量使用導致目標碼指數級增長
- 指令快取命中率下降、分頁調度增加、效能反而惡化
- 嵌入式/記憶體受限環境尤為危險
關鍵認知：inline 是請求而非命令
編譯器有權拒絕：
- 過於複雜函數（含迴圈、遞迴、大量程式碼）
- 虛函數呼叫（動態綁定與靜態展開本質衝突）
- 透過函數指標呼叫（編譯期無法確定目標）
大多數編譯器提供診斷警告告知無法內聯情況。
隱性 inline 請求來源
- 類別定義內定義的成員函數（隱性 inline）
- 友元函數定義於類別內部
- 顯式
inline 關鍵字
- 函數模板常置於頭文件，但模板不等於 inline——需顯式宣告
建構/解構函數：inline 的重災區
看似空白的建構函數實則隱含大量編譯器生成代碼：
class Base { string bm1, bm2; };
class Derived : public Base {
public:
Derived() {} // 看似空白
private:
string dm1, dm2, dm3;
};
實際展開包含：基類建構、5 個 string 建構、異常安全回滾邏輯。若 string 建構函數也是 inline，程式碼膨脹極其嚴重。
庫設計的二進制相容性陷阱
公開介面的 inline 函數編譯進客戶端程式碼，修改後所有客戶端必須重新編譯。非 inline 僅需重新連結，動態連結庫甚至透明升級。這是庫設計者的關鍵決策點。
除錯器相容性考量
多數除錯器難以處理 inline 函數（無法在不存在的函數設中斷點）。常見做法：除錯建構關閉 inline。
黃金策略：80-20 法則指導下的審慎內聯
- 預設不 inline，或僅限「必須 inline」與「極簡單」函數
- 保持除錯友善、二進制升級彈性、最小化碼膨脹風險
- 識別熱點 20% 程式碼（分析器輔助），針對性優化
- 模板不自動 inline，僅在確認收益時顯式宣告
核心箴言
- 將 inline 限制於小型、高頻呼叫函數
- 勿因模板在頭文件就宣告 inline——兩者無必然關聯
- inline 是手動優化工具，非預設編碼風格
