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