青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

<2009年4月>
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

統(tǒng)計(jì)

  • 隨筆 - 24
  • 文章 - 0
  • 評論 - 17
  • 引用 - 0

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

相冊

搜索

  •  

最新評論

閱讀排行榜

評論排行榜

用C實(shí)現(xiàn)的一個基本COM接口IFoo(來自COM Programmer's Cookbook)——C實(shí)現(xiàn)COM接口系列1

用C實(shí)現(xiàn)的一個基本COM接口IFoo(來自COM Programmer's Cookbook)


把該文中實(shí)現(xiàn)的代碼整理匯總到一個項(xiàng)目中。目前只是實(shí)現(xiàn)到一個中間階段,重點(diǎn)在說明COM接口的實(shí)現(xiàn)原理,還沒有包含類廠的部分。以后還需陸續(xù)添加類廠等高級功能。

文件組成:
ifoo.h         COM接口IFoo,接口ID IID_IFoo 聲明文件。
outside.c      COM接口實(shí)現(xiàn)。這里實(shí)現(xiàn)IFoo的是一個結(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接口是一個指向虛函數(shù)表的指針。通過這個指針可以訪問內(nèi)存中某處的各個功能塊,執(zhí)行預(yù)定義的功能,完成用戶的任務(wù)。這些功能塊以函數(shù)的形式存在(想不出還有其他形式:))并被調(diào)用。它們有一個共同點(diǎn):都包含一個指針參數(shù),指向這些功能要操作的數(shù)據(jù)地址。在C++中,這個地址就是對象的首地址,也就是類成員函數(shù)中隱含的this指針。在C函數(shù)中并沒有這種現(xiàn)成的便利,因此代碼實(shí)現(xiàn)中在接口定義時仍使用了接口指針(HRESULT (__stdcall * QueryInterface)   (IFoo * This,  const IID * const, void **)),而在接口函數(shù)實(shí)現(xiàn)時根據(jù)結(jié)構(gòu)體布局結(jié)構(gòu),從這個接口指針推算得到對象實(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接口的要求:

每一個COM接口(指向的虛函數(shù)表)的頭三個函數(shù)必須是IUnknown接口的函數(shù):QueryInterface,AddRef和Release。在C++中,稱為從IUnknown接口繼承。
對于調(diào)用QueryInterface響應(yīng)查詢IID_IUnknwon得到的接口指針值,同一個對象實(shí)現(xiàn)的所有接口必須相同。這是判斷兩個COM對象是否是同一個對象的標(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)該記錄每一個變量、表達(dá)式的類型。當(dāng)進(jìn)行強(qiáng)制類型轉(zhuǎn)換時,就(臨時地)修改其類型為轉(zhuǎn)換到的類型。
同理,QueryInterface, AddRef, Release宏定義中的(IUnknown *)也是這種用法。

可以看到,宏“IUNK_VTABLE_OF“的作用是供宏QueryInterface,宏AddRef,宏Release引用,把IFooVtbl *類型轉(zhuǎn)換為IUnknownVtbl *類型,最終達(dá)到調(diào)用IUnknownVtbl中定義的三個QueryInterface,AddRef,Release函數(shù)。

那么,這種大費(fèi)周章的目的是什么呢?為什么不以IFooVtbl中三個函數(shù)的定義形式(不通過強(qiáng)制轉(zhuǎn)換來轉(zhuǎn)換成必須的類型),直接調(diào)用IFooVtbl中定義的函數(shù)呢?雖然強(qiáng)制轉(zhuǎn)換在參數(shù)值上并不會造成改變,最終調(diào)用的也是IFooVtbl定義的函數(shù)(FooQueryInterface,FooAddRef,FooRelease)。

為什么一定要通過IUnknown接口指針調(diào)用這三個函數(shù)呢?修改QueryInterface宏定義如下:
#define QueryInterface(pif, iid, pintf) \
 (((pif)->lpVtbl)->QueryInterface(pif, iid, (void **)(pintf)))
即通過IFoo接口指針來調(diào)用由IUnknown引入的函數(shù),有什么不對的地方嗎?

試驗(yàn)表明,將QueryInterface宏定義如下也可以編譯通過,執(zhí)行起來也沒有出現(xiàn)任何異常。
#define QueryInterface(pif, iid, pintf) \
 (((pif)->lpVtbl)->QueryInterface(pif, iid, (void **)(pintf)))

 

對于IUnknown接口的三個函數(shù),調(diào)用時傳遞的參數(shù)是IUnknown *類型(見QueryInterface, AddRef, Release宏定義),而函數(shù)定義中(FooQueryInterface, FooAddRef, FooRelease)聲明的參數(shù)是IFoo *類型,這種不一致的情況是怎么出現(xiàn)的?這種不一致不會有問題嗎?

這種不一致的產(chǎn)生是由于從不同的角度看待引起的。如果從IUnknown接口來看,那么接口函數(shù)中的第一個參數(shù)類型就是IUnknown *;如果從IFoo來看,那么第一個參數(shù)的類型就是IFoo *。

這種不一致性只是針對于編譯器對于類型的編譯要求有意義的,在接口實(shí)現(xiàn)及使用時,傳遞給lpVtbl->QueryInterface, lpVtbl->AddRef,lpVtbl->Release的第一個參數(shù)在值上都是相同的,都是實(shí)現(xiàn)該接口的內(nèi)存地址(在本例中是COutside對象的首地址)。

 

一些語法現(xiàn)象回顧

函數(shù)指針變量定義、賦值及調(diào)用。
HRESULT (__stdcall * pQI)   (IFoo * This,  const IID * const, void **) ;
定義一個函數(shù)指針變量pQI,該變量指向“返回HRESULT,取3個參數(shù)分別為類型IFoo *,const IID * const, void **”的函數(shù)。

typedef HRESULT (__stdcall * QIType)   (IFoo * This,  const IID * const, void **) ;
定義一個函數(shù)指針類型,該類型的指針指向“返回HRESULT,取3個參數(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; // 與上面等價。

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ī)則
對于宏,一直有一種霧里看花的感覺,似乎很隨意,怎么來都行,比如:
#define AddRef(pif) \
 (IUNK_VTABLE_OF(pif)->AddRef((IUnknown *)(pif)))

宏定義應(yīng)該是可以嵌套的,即宏定義的“內(nèi)容“中還可以包含(嵌套)宏,如本例,“IUNK_VTABLE_OF”就是嵌套宏。在展開的時候,將嵌套的宏也一并展開(替換成定義的內(nèi)容),直到不再有宏為止。
那么就有兩個疑問:
1。如果被嵌套的宏包含(直接或間接)定義的宏,那么展開就沒完沒了,死循環(huán)了。
2。如果定義的內(nèi)容中有跟定義的宏同名的字符串(比如上面的例子IUNK_VTABLE_OF),那么怎么區(qū)分這同名的東東是嵌套的宏(需要展開),還是一般的字符串(不需要展開)?


函數(shù)調(diào)用規(guī)范約定、main函數(shù)調(diào)用規(guī)范。

一開始把幾個文件匯總到項(xiàng)目里時,編譯通不過,錯誤提示大致意思是,不能把一種調(diào)用規(guī)范的函數(shù)指針轉(zhuǎn)換成另一種調(diào)用規(guī)范的函數(shù)指針。后來把調(diào)用規(guī)范改為   /Gz(__stdcall),編譯為(Compile As)改為/TC(Compile As C Code)就好了。

想來是對于.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”處的成員是一大忌,會造成GP。然而,取地址“0”處的成員的地址,卻是個合法的操作。雖然地址“0”處并沒有什么內(nèi)容,但是,如果在地址0處存放一個內(nèi)容,那么該內(nèi)容中的成員也是有地址的。本例中正是巧妙地利用這種方法,從接口地址計(jì)算得出實(shí)現(xiàn)該接口的實(shí)例地址,進(jìn)而訪問實(shí)例的內(nèi)部變量。

------------------------------------------------------------------------------------
2009年5月6日
附上源碼:/Files/gracelee/outside.zip

代碼執(zhí)行結(jié)果:

posted on 2009-04-29 12:08 小蔥蘸醬 閱讀(2006) 評論(3)  編輯 收藏 引用 所屬分類: 編碼點(diǎn)滴

評論

# re: 用C實(shí)現(xiàn)的一個基本COM接口IFoo(來自COM Programmer's Cookbook)——C實(shí)現(xiàn)COM接口系列1 2009-04-29 21:40 likenk

很好,現(xiàn)在講com的資料非常少,希望lz能繼續(xù)下去,講的易懂些。先謝謝啦。
  回復(fù)  更多評論    

# re: 用C實(shí)現(xiàn)的一個基本COM接口IFoo(來自COM Programmer's Cookbook)——C實(shí)現(xiàn)COM接口系列1 2009-04-30 11:16 xcpp

強(qiáng)大
  回復(fù)  更多評論    

# re: 用C實(shí)現(xiàn)的一個基本COM接口IFoo(來自COM Programmer's Cookbook)——C實(shí)現(xiàn)COM接口系列1 2009-05-17 11:03 flyceit

真是太棒了!希望作者堅(jiān)持下去.
  回復(fù)  更多評論    
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            久久在线视频在线| 美女网站久久| 国产欧美一区二区精品秋霞影院| 亚洲欧美成人一区二区在线电影 | 国内精品久久久久影院色| 久久狠狠婷婷| 久久在线视频| 亚洲一区二区少妇| 亚洲欧美日韩一区二区| 国内精品久久久久影院优| 欧美a级在线| 国产精品久久久久9999吃药| 久久精品官网| 欧美黄色成人网| 亚洲欧美卡通另类91av| 欧美一区二区性| 99精品热6080yy久久 | 欧美国产在线观看| 欧美日韩一区二区三区在线观看免| 亚洲欧美精品在线| 久久噜噜亚洲综合| 亚洲午夜精品久久久久久app| 亚洲欧美在线观看| 一本色道久久88精品综合| 亚洲网站在线| 91久久精品美女| 午夜欧美精品| 99精品视频免费观看| 欧美一区午夜视频在线观看| 日韩视频一区二区三区在线播放免费观看 | 久久精品国产清自在天天线| 你懂的网址国产 欧美| 亚洲在线成人精品| 久久中文字幕一区二区三区| 欧美一级黄色录像| 欧美精品粉嫩高潮一区二区| 久久亚洲综合网| 国产精品久久九九| 亚洲乱码国产乱码精品精| 激情偷拍久久| 午夜在线精品| 亚洲一区欧美激情| 欧美高清视频一区| 玖玖在线精品| 亚洲免费中文| 亚洲一区免费网站| 欧美日韩免费观看一区=区三区| 欧美成人免费全部| 今天的高清视频免费播放成人| 一区二区三区视频在线 | 国产精品美女一区二区在线观看| 亚洲国产岛国毛片在线| 国内伊人久久久久久网站视频| 亚洲一区二区三区精品视频| 中日韩视频在线观看| 欧美精品激情| 亚洲国产精品视频| 亚洲欧洲日本国产| 欧美成人国产va精品日本一级| 久久久久久久性| 国产亚洲aⅴaaaaaa毛片| 亚洲午夜久久久久久久久电影院| 国产精品99久久久久久宅男| 欧美激情区在线播放| 亚洲狠狠丁香婷婷综合久久久| 亚洲国产欧美精品| 欧美成年人视频| 亚洲国产成人久久综合一区| 亚洲精品日韩久久| 欧美激情视频给我| 一区二区三区视频观看| 亚洲欧美一区二区三区在线| 国产精品免费一区二区三区在线观看 | 午夜一级久久| 狂野欧美激情性xxxx| 亚洲国产日韩一区| 欧美国产日韩a欧美在线观看| 亚洲精品小视频在线观看| 亚洲先锋成人| 国产日韩欧美综合精品| 欧美中文字幕第一页| 嫩草影视亚洲| 一本大道久久a久久综合婷婷| 欧美亚州在线观看| 亚洲欧美不卡| 欧美成人免费在线视频| 日韩午夜av| 国产女主播一区| 久久视频在线看| 日韩视频国产视频| 久久精品国产99精品国产亚洲性色| 国模一区二区三区| 欧美激情在线观看| 性做久久久久久久免费看| 久久综合网hezyo| 亚洲一级电影| 尤物在线精品| 国产精品啊v在线| 久久久亚洲国产天美传媒修理工| 亚洲美女av网站| 久久久亚洲精品一区二区三区| 亚洲三级影片| 国产在线欧美日韩| 欧美日韩精品免费观看| 久久aⅴ国产欧美74aaa| 亚洲乱码一区二区| 欧美成人精品福利| 欧美一区二区三区的| 亚洲国产中文字幕在线观看| 国产精品系列在线| 日韩午夜免费| 嫩草伊人久久精品少妇av杨幂| 亚洲一区二区三区激情| 激情小说另类小说亚洲欧美| 欧美特黄一区| 欧美电影免费观看高清| 欧美一区二区三区免费在线看| 亚洲美女视频在线免费观看| 久久综合九色综合欧美就去吻| 亚洲一区二区精品在线观看| 亚洲国产精品免费| 国产一区二区高清不卡| 国产精品成人免费精品自在线观看| 免费国产自线拍一欧美视频| 亚洲欧美成人一区二区在线电影 | 久久婷婷丁香| 亚洲欧美国产精品桃花| 99亚洲视频| 亚洲精品一区二区网址| 在线观看亚洲视频| 国产真实久久| 国产亚洲综合在线| 国产精品日韩欧美| 国产精品av久久久久久麻豆网| 欧美成人免费大片| 蜜臀va亚洲va欧美va天堂| 欧美在线视频免费| 久久国产精品99国产精| 午夜精品久久久| 亚洲欧美一级二级三级| 亚洲影院色在线观看免费| 一区二区动漫| 在线综合+亚洲+欧美中文字幕| 999亚洲国产精| 日韩亚洲国产精品| 一本大道久久a久久精二百| 亚洲精品无人区| av成人免费在线| 一区二区三区四区在线| 亚洲视频久久| 欧美亚洲在线观看| 久久久999国产| 老鸭窝亚洲一区二区三区| 免播放器亚洲| 欧美日韩天堂| 国产在线精品二区| 亚洲高清色综合| 99综合视频| 羞羞漫画18久久大片| 久久嫩草精品久久久久| 美女在线一区二区| 亚洲欧洲日本一区二区三区| 一本色道久久精品| 欧美一区二区在线免费播放| 葵司免费一区二区三区四区五区| 欧美成人精品影院| 欧美性事在线| 在线激情影院一区| 一区二区三区www| 久久成人精品电影| 亚洲第一区色| 亚洲免费一在线| 久久精品国产一区二区三| 欧美激情成人在线| 国产精品久久久久久久久借妻 | 亚洲欧美日本国产有色| 久久免费视频在线| 99av国产精品欲麻豆| 欧美一区二区三区在线看| 欧美风情在线| 国产性猛交xxxx免费看久久| 亚洲伦理一区| 久久久www| 亚洲精品乱码久久久久久蜜桃91| 制服丝袜亚洲播放| 欧美在线关看| 欧美视频在线不卡| 欧美日本韩国| 在线电影国产精品| 午夜精品久久久久久久久久久久久 | 久久精品国内一区二区三区| 欧美承认网站| 国产在线视频欧美| 亚洲天堂av图片| 亚洲大黄网站| 欧美在线视频一区二区| 欧美激情在线免费观看| 一区三区视频| 久久九九国产精品怡红院| 中日韩男男gay无套|