COM 開發核心：Variant 與 IDispatch 深度解析

前言

在 Windows COM 程式設計中，Variant 與 IDispatch 是支撐腳本語言、動態綁定與跨語言互操作的兩大基石。本文將從結構定義、設計動機、實現機制三個維度，深度剖析這兩大核心技術，並釐清「雙介面」的真實含義。

Variant：萬能數據容器

為什麼需要 Variant？

C++ 是強類型語言，變量類型在編譯期確定。但 Visual Basic、JavaScript 等腳本語言採用弱類型或動態類型，變量可在運行時改變類型。為了讓 C++ 組件能與這些語言交換數據，COM 引入了 VARIANT —— 一個能存放「幾乎所有類型」數據的結構體。

內部結構剖析

VARIANT 本質是一個巨大的 union，包含 VARTYPE vt 標識當前實際類型，以及各類數據字段：

struct tagVARIANT {
    VARTYPE vt;           // 類型標譤
    WORD wReserved1, wReserved2, wReserved3;
    union {
        LONG lVal;        // 32 位整數
        DOUBLE dblVal;    // 雙精度浮點
        BSTR bstrVal;     // 字符串
        IDispatch *pdispVal; // IDispatch 指針
        SAFEARRAY *parray;   // 安全數組
        // ... 大量其他類型與指針變體
        struct { PVOID pvRecord; IRecordInfo *pRecInfo; } __VARIANT_NAME_4; // 用戶定義類型
    };
};

這就是為什麼 C++ 程式員覺得它「超級複雜」——它其實是一個手工實現的「類型安全聯合體」。

使用痛點

• C/C++ 無原生語法支持，操作需調用 VariantInit、VariantClear、VariantChangeType 等 API
• 易發生內存洩漏（如 BSTR、SAFEARRAY 未正確釋放）
• 類型轉換錯誤難以編譯期發現

相比之下，Delphi、C# 等語言提供內置 Variant 支持，大幅降低使用門檻。

IDispatch：晚綁定的橋樑

設計動機：腳本語言的調用需求

腳本語言（解釋執行）無法像 C++ 那樣在編譯期綁定虛函數表地址。它們需要：在完全不知組件介面定義的情況下，通過名稱或 ID 動態調用方法/屬性。這就是「晚綁定」。

IDispatch 正是為此而生的標準化規範，核心方法：

• GetIDsOfNames：將方法名（字符串）映射為 DISPID
• Invoke：根據 DISPID、參數包（DISPPARAMS，內含 VARIANT 數組）執行調用，返回 VARIANT 結果

這與 Windows 消息機制（uMsg + wParam/lParam）極其相似：DISPID 對應消息 ID，DISPPARAMS 對應參數結構。

早綁定 vs 晚綁定

雙介面：兩全其美的設計

常見誤區

許多人誤以為「繼承自 IDispatch 的介面就是雙介面」。實際上：

雙介面 = 同時實現 IDispatch（晚綁定）與 vtable 介面（早綁定）

IDL 定義

[dual]
interface IFoo : IDispatch {
    HRESULT foo(int arg1, int arg2);
};

• [dual] 屬性指示 MIDL 編譯器生成雙重調用機制
• C++ 客戶端可直接通過 vtable 高效調用 foo
• 腳本客戶端可通過 IDispatch::Invoke 動態調用同一方法
• IFoo 必須繼承自 IDispatch，但繼承 IDispatch 的介面不一定是雙介面

優勢

1. 性能與兼容並存：C++ 享受零開銷直接調用，腳本語言獲得動態性
2. 類型庫支持：GetTypeInfo 提供完整元數據，支援智能提示、自動完成
3. 單一介面定義：無需維護兩套獨立介面

總結

• VARIANT 是跨語言數據交換的「通用貨幣」，代價是複雜度與運行期風險
• IDispatch 實現了「不知介面仍能調用」的晚綁定機制，核心是 DISPID + Invoke
• 雙介面（[dual]）是 COM 為兼顧效率與靈活性而設計的混合模式，是 Automation 組件的標準選擇

理解這三者關係，是掌握 COM/Automation 開發的關鍵一環。