用C實(shí)現(xiàn)的一個(gè)基本COM接口IFoo（來自COM Programmer's Cookbook）
把該文中實(shí)現(xiàn)的代碼整理匯總到一個(gè)項(xiàng)目中。目前只是實(shí)現(xiàn)到一個(gè)中間階段，重點(diǎn)在說明COM接口的實(shí)現(xiàn)原理，還沒有包含類廠的部分。以后還需陸續(xù)添加類廠等高級(jí)功能。
文件組成：
ifoo.h COM接口IFoo,接口ID IID_IFoo 聲明文件。
outside.c COM接口實(shí)現(xiàn)。這里實(shí)現(xiàn)IFoo的是一個(gè)結(jié)構(gòu)體COutside.
util.h 一些宏定義、全局函數(shù)、變量聲明文件。
main.c 筆者為實(shí)現(xiàn)項(xiàng)目添加的文件。提供main函數(shù)、內(nèi)存管理函數(shù)Alloc,Free的實(shí)現(xiàn)（封裝C運(yùn)行庫函數(shù)malloc和free.）、接口ID定義。
COM接口到底是什么？
COM接口是一個(gè)指向虛函數(shù)表的指針。通過這個(gè)指針可以訪問內(nèi)存中某處的各個(gè)功能塊，執(zhí)行預(yù)定義的功能，完成用戶的任務(wù)。這些功能塊以函數(shù)的形式存在（想不出還有其他形式:)）并被調(diào)用。它們有一個(gè)共同點(diǎn)：都包含一個(gè)指針參數(shù)，指向這些功能要操作的數(shù)據(jù)地址。在C++中，這個(gè)地址就是對(duì)象的首地址，也就是類成員函數(shù)中隱含的this指針。在C函數(shù)中并沒有這種現(xiàn)成的便利，因此代碼實(shí)現(xiàn)中在接口定義時(shí)仍使用了接口指針（HRESULT (__stdcall * QueryInterface) (IFoo * This, const IID * const, void **)），而在接口函數(shù)實(shí)現(xiàn)時(shí)根據(jù)結(jié)構(gòu)體布局結(jié)構(gòu)，從這個(gè)接口指針推算得到對(duì)象實(shí)例指針。
typedef struct IFoo
{
struct IFooVtbl * lpVtbl;
} IFoo;
typedef struct IFooVtbl IFooVtbl;
struct IFooVtbl
{
HRESULT (__stdcall * QueryInterface) (IFoo * This, const IID * const, void **) ;
ULONG (__stdcall * AddRef) (IFoo * This) ;
ULONG (__stdcall * Release) (IFoo * This) ;
HRESULT (__stdcall * SetValue) (IFoo * This, int) ;
HRESULT (__stdcall * GetValue) (IFoo * This, int *) ;
};
COM接口的要求：
每一個(gè)COM接口（指向的虛函數(shù)表）的頭三個(gè)函數(shù)必須是IUnknown接口的函數(shù)：QueryInterface,AddRef和Release。在C++中，稱為從IUnknown接口繼承。
對(duì)于調(diào)用QueryInterface響應(yīng)查詢IID_IUnknwon得到的接口指針值，同一個(gè)對(duì)象實(shí)現(xiàn)的所有接口必須相同。這是判斷兩個(gè)COM對(duì)象是否是同一個(gè)對(duì)象的標(biāo)準(zhǔn)。
宏定義“#define IUNK_VTABLE_OF(x) ((IUnknownVtbl *)((x)->lpVtbl))“說明
在預(yù)處理輸出文件main.i中可以找到IUnknownVtbl和IFooVtbl的聲明：
typedef struct IUnknownVtbl
{
HRESULT ( __stdcall *QueryInterface )(
IUnknown * This,
const IID * const riid,
void **ppvObject);
ULONG ( __stdcall *AddRef )(
IUnknown * This);
ULONG ( __stdcall *Release )(
IUnknown * This);
} IUnknownVtbl;
struct IUnknown
{
struct IUnknownVtbl *lpVtbl;
};
struct IFooVtbl
{
HRESULT (__stdcall * QueryInterface) (IFoo * This, const IID * const, void **) ;
ULONG (__stdcall * AddRef) (IFoo * This) ;
ULONG (__stdcall * Release) (IFoo * This) ;
HRESULT (__stdcall * SetValue) (IFoo * This, int) ;
HRESULT (__stdcall * GetValue) (IFoo * This, int *) ;
};
該宏定義的作用就是把IFoo接口中的IFooVtbl類型的指針拿出來（(x)->lpVtbl)），并強(qiáng)制轉(zhuǎn)換（(IUnknownVtbl *)）成IUnknownVtbl。
“強(qiáng)制轉(zhuǎn)換”的結(jié)果是什么呢？是怎么做到的呢？
很明顯，結(jié)果就是得到的指針不再是IFooVtbl *類型，而是變成了IUnknownVtbl *類型。至于做法，系統(tǒng)應(yīng)該記錄每一個(gè)變量、表達(dá)式的類型。當(dāng)進(jìn)行強(qiáng)制類型轉(zhuǎn)換時(shí)，就（臨時(shí)地）修改其類型為轉(zhuǎn)換到的類型。
同理，QueryInterface, AddRef, Release宏定義中的(IUnknown *)也是這種用法。
可以看到，宏“IUNK_VTABLE_OF“的作用是供宏QueryInterface,宏AddRef，宏Release引用，把IFooVtbl *類型轉(zhuǎn)換為IUnknownVtbl *類型，最終達(dá)到調(diào)用IUnknownVtbl中定義的三個(gè)QueryInterface,AddRef,Release函數(shù)。
那么，這種大費(fèi)周章的目的是什么呢？為什么不以IFooVtbl中三個(gè)函數(shù)的定義形式（不通過強(qiáng)制轉(zhuǎn)換來轉(zhuǎn)換成必須的類型），直接調(diào)用IFooVtbl中定義的函數(shù)呢？雖然強(qiáng)制轉(zhuǎn)換在參數(shù)值上并不會(huì)造成改變，最終調(diào)用的也是IFooVtbl定義的函數(shù)（FooQueryInterface,FooAddRef,FooRelease）。
為什么一定要通過IUnknown接口指針調(diào)用這三個(gè)函數(shù)呢？修改QueryInterface宏定義如下：
#define QueryInterface(pif, iid, pintf) \
(((pif)->lpVtbl)->QueryInterface(pif, iid, (void **)(pintf)))
即通過IFoo接口指針來調(diào)用由IUnknown引入的函數(shù)，有什么不對(duì)的地方嗎？
試驗(yàn)表明，將QueryInterface宏定義如下也可以編譯通過，執(zhí)行起來也沒有出現(xiàn)任何異常。
#define QueryInterface(pif, iid, pintf) \
(((pif)->lpVtbl)->QueryInterface(pif, iid, (void **)(pintf)))
對(duì)于IUnknown接口的三個(gè)函數(shù)，調(diào)用時(shí)傳遞的參數(shù)是IUnknown *類型（見QueryInterface, AddRef, Release宏定義），而函數(shù)定義中（FooQueryInterface, FooAddRef, FooRelease）聲明的參數(shù)是IFoo *類型，這種不一致的情況是怎么出現(xiàn)的？這種不一致不會(huì)有問題嗎？
這種不一致的產(chǎn)生是由于從不同的角度看待引起的。如果從IUnknown接口來看，那么接口函數(shù)中的第一個(gè)參數(shù)類型就是IUnknown *;如果從IFoo來看，那么第一個(gè)參數(shù)的類型就是IFoo *。
這種不一致性只是針對(duì)于編譯器對(duì)于類型的編譯要求有意義的，在接口實(shí)現(xiàn)及使用時(shí)，傳遞給lpVtbl->QueryInterface, lpVtbl->AddRef,lpVtbl->Release的第一個(gè)參數(shù)在值上都是相同的，都是實(shí)現(xiàn)該接口的內(nèi)存地址（在本例中是COutside對(duì)象的首地址）。
一些語法現(xiàn)象回顧
函數(shù)指針變量定義、賦值及調(diào)用。
HRESULT (__stdcall * pQI) (IFoo * This, const IID * const, void **) ;
定義一個(gè)函數(shù)指針變量pQI,該變量指向“返回HRESULT,取3個(gè)參數(shù)分別為類型IFoo *,const IID * const, void **”的函數(shù)。
typedef HRESULT (__stdcall * QIType) (IFoo * This, const IID * const, void **) ;
定義一個(gè)函數(shù)指針類型，該類型的指針指向“返回HRESULT,取3個(gè)參數(shù)分別為類型IFoo *,const IID * const, void **”的函數(shù)。
HRESULT __stdcall QueryInterface(IFoo * This, const IID * const, void **) ;//函數(shù)聲明示例
pQI = 0; // 函數(shù)指針賦值，0表示不指向任何函數(shù)。
pQI = QueryInterface; // 函數(shù)指針賦值，pQI指向QueryInterface。
pQI = &QueryInterface; // 與上面等價(jià)。
QueryInterface(&this->ifoo, riid, ppv); // 使用函數(shù)名直接調(diào)用
pQI(&this->ifoo, riid, ppv); // 函數(shù)指針調(diào)用
(*pQI)(&this->ifoo, riid, ppv); // 第二種函數(shù)指針調(diào)用方式
宏定義、展開規(guī)則
對(duì)于宏，一直有一種霧里看花的感覺，似乎很隨意，怎么來都行，比如：
#define AddRef(pif) \
(IUNK_VTABLE_OF(pif)->AddRef((IUnknown *)(pif)))
宏定義應(yīng)該是可以嵌套的，即宏定義的“內(nèi)容“中還可以包含（嵌套）宏，如本例，“IUNK_VTABLE_OF”就是嵌套宏。在展開的時(shí)候，將嵌套的宏也一并展開（替換成定義的內(nèi)容），直到不再有宏為止。
那么就有兩個(gè)疑問：
1。如果被嵌套的宏包含（直接或間接）定義的宏，那么展開就沒完沒了，死循環(huán)了。
2。如果定義的內(nèi)容中有跟定義的宏同名的字符串（比如上面的例子IUNK_VTABLE_OF），那么怎么區(qū)分這同名的東東是嵌套的宏（需要展開），還是一般的字符串（不需要展開）？
函數(shù)調(diào)用規(guī)范約定、main函數(shù)調(diào)用規(guī)范。
一開始把幾個(gè)文件匯總到項(xiàng)目里時(shí)，編譯通不過，錯(cuò)誤提示大致意思是，不能把一種調(diào)用規(guī)范的函數(shù)指針轉(zhuǎn)換成另一種調(diào)用規(guī)范的函數(shù)指針。后來把調(diào)用規(guī)范改為 /Gz(__stdcall),編譯為（Compile As）改為/TC(Compile As C Code)就好了。
想來是對(duì)于.c文件，編譯器缺省使用的是__cdecl，而IFoo中的接口宏定義在win32下展開成了__stdcall，所以出現(xiàn)了矛盾。而使用/Gz強(qiáng)制未聲明調(diào)用規(guī)范的函數(shù)使用__stdcall，實(shí)現(xiàn)就與聲明一致了。
(size_t)&(((s *)0)->m)
c++程序員也許都知道，訪問地址“0”處的成員是一大忌，會(huì)造成GP。然而，取地址“0”處的成員的地址，卻是個(gè)合法的操作。雖然地址“0”處并沒有什么內(nèi)容，但是，如果在地址0處存放一個(gè)內(nèi)容，那么該內(nèi)容中的成員也是有地址的。本例中正是巧妙地利用這種方法，從接口地址計(jì)算得出實(shí)現(xiàn)該接口的實(shí)例地址，進(jìn)而訪問實(shí)例的內(nèi)部變量。
------------------------------------------------------------------------------------
2009年5月6日
附上源碼：/Files/gracelee/outside.zip
代碼執(zhí)行結(jié)果：
