Effective C# 原則 46：最小化與非托管代碼互操作 (下)

P/Invoke 的侷限

僅能存取 C 風格 Win32 函式，手寫介面宣告開銷大，非高產做法。

混合模式 C++ (/clr) 建立橋接層

以 /clr 編譯原生 C++ 程式碼產生 MSIL 庫，但資料仍在原生堆，無法直接被 C# 呼叫。需建立受控包裝類別：

public __gc class ManagedWrapper : IDisposable
{
    private: NativeType* _pMyClass;
    public: ManagedWrapper() : _pMyClass(new NativeType()) { }
    virtual void Dispose() { delete _pMyClass; _pMyClass = NULL; GC::SuppressFinalize(this); }
    ~ManagedWrapper() { delete _pMyClass; }
    __property String* get_Name() { return _pMyClass->Name(); }
    __property void set_Name(String* value) { /* 字串轉換與複製 */ }
    void DOStuff() { _pMyClass->DOStuff(); }
}

優缺點權衡

• 優點：可控制原生方法/屬性暴露細節。
• 缺點：大量重複程式碼、托管/非托管資料封送、手寫雙語言易出錯、需手動刪除非托管物件。

/clr 非銀彈

• C++ 模板與例外處理與 C# 差異大，優質 C++ 不一定產生最佳 MSIL。
• /clr 程式碼使用原生堆，CLR 無法驗證安全性，呼叫端需 SecurityPermission 執行非受信程式碼。

但對於非 COM 的現有 C++ 程式碼，/clr 仍是最佳策略：無 thunking 開銷，原生 CPU 指令效能最佳。

策略選擇建議

• 有現有 COM 物件 → COM Interop。
• 有現有 C++ 程式碼 → /clr + 受控 C++ 包裝。
• 重寫成本可接受 → 「直接丟棄」策略（全用 C# 重寫）。

互操作痛苦，認真評估是否必要。