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

<2006年9月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

統(tǒng)計

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

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

相冊

搜索

  •  

最新評論

閱讀排行榜

評論排行榜

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

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


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

文件組成:
ifoo.h         COM接口IFoo,接口ID IID_IFoo 聲明文件。
outside.c      COM接口實現(xiàn)。這里實現(xiàn)IFoo的是一個結(jié)構(gòu)體COutside.
util.h         一些宏定義、全局函數(shù)、變量聲明文件。
main.c         筆者為實現(xiàn)項目添加的文件。提供main函數(shù)、內(nèi)存管理函數(shù)Alloc,Free的實現(xiàn)(封裝C運行庫函數(shù)malloc和free.)、接口ID定義。

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

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得到的接口指針值,同一個對象實現(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)),并強制轉(zhuǎn)換((IUnknownVtbl *))成IUnknownVtbl。
“強制轉(zhuǎn)換”的結(jié)果是什么呢?是怎么做到的呢?
很明顯,結(jié)果就是得到的指針不再是IFooVtbl *類型,而是變成了IUnknownVtbl *類型。至于做法,系統(tǒng)應(yīng)該記錄每一個變量、表達式的類型。當(dāng)進行強制類型轉(zhuǎn)換時,就(臨時地)修改其類型為轉(zhuǎn)換到的類型。
同理,QueryInterface, AddRef, Release宏定義中的(IUnknown *)也是這種用法。

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

那么,這種大費周章的目的是什么呢?為什么不以IFooVtbl中三個函數(shù)的定義形式(不通過強制轉(zhuǎn)換來轉(zhuǎn)換成必須的類型),直接調(diào)用IFooVtbl中定義的函數(shù)呢?雖然強制轉(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ù),有什么不對的地方嗎?

試驗表明,將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 *。

這種不一致性只是針對于編譯器對于類型的編譯要求有意義的,在接口實現(xiàn)及使用時,傳遞給lpVtbl->QueryInterface, lpVtbl->AddRef,lpVtbl->Release的第一個參數(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ī)范。

一開始把幾個文件匯總到項目里時,編譯通不過,錯誤提示大致意思是,不能把一種調(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強制未聲明調(diào)用規(guī)范的函數(shù)使用__stdcall,實現(xiàn)就與聲明一致了。


(size_t)&(((s *)0)->m)

c++程序員也許都知道,訪問地址“0”處的成員是一大忌,會造成GP。然而,取地址“0”處的成員的地址,卻是個合法的操作。雖然地址“0”處并沒有什么內(nèi)容,但是,如果在地址0處存放一個內(nèi)容,那么該內(nèi)容中的成員也是有地址的。本例中正是巧妙地利用這種方法,從接口地址計算得出實現(xiàn)該接口的實例地址,進而訪問實例的內(nèi)部變量。

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

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

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

評論

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

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

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

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

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

真是太棒了!希望作者堅持下去.
  回復(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>
            1024精品一区二区三区| 亚洲福利专区| 亚洲在线视频观看| 夜夜夜精品看看| 99精品国产在热久久下载| 亚洲第一精品夜夜躁人人爽| 欧美电影在线观看完整版| 欧美在线免费观看视频| 久久国产精品久久久久久电车 | 国产精品福利片| 国产精品大全| 国产日韩一区二区| 在线观看欧美精品| 99热免费精品在线观看| 亚洲女女女同性video| 久久久久久久久久久一区| 欧美高清在线播放| 一本一道久久综合狠狠老精东影业 | 美女任你摸久久| 欧美日韩大陆在线| 国产婷婷成人久久av免费高清| 精品不卡在线| 亚洲小说欧美另类社区| 久久久人成影片一区二区三区| 免费中文日韩| 亚洲在线观看免费视频| 欧美肥婆在线| 国产一区二区三区精品欧美日韩一区二区三区 | 亚洲在线成人精品| 免费欧美高清视频| 亚洲夜间福利| 欧美激情国产日韩| 伊人久久av导航| 亚洲自啪免费| 欧美高清不卡在线| 亚洲欧美中文另类| 欧美三级网址| 亚洲日本在线观看| 久久综合99re88久久爱| 亚洲麻豆一区| 久久亚洲私人国产精品va| 国产精品免费视频xxxx| 99精品久久免费看蜜臀剧情介绍| 久久亚洲精品视频| 亚洲欧美日韩综合一区| 欧美日韩另类视频| 亚洲乱码国产乱码精品精| 美女日韩欧美| 国产精品99久久久久久久久久久久 | 久久精品人人做人人综合| 亚洲精品国产系列| 亚洲欧美综合网| 欧美视频在线观看一区二区| 亚洲久久成人| 亚洲日本成人网| 欧美激情视频给我| 亚洲区欧美区| 91久久在线观看| 欧美国产精品va在线观看| 亚洲电影毛片| 欧美国产视频日韩| 女同性一区二区三区人了人一| 亚洲国产成人在线播放| 欧美成人精品在线视频| 久久夜色精品国产欧美乱极品| 韩国一区二区在线观看| 久久精品一区二区三区四区| 欧美在线一二三区| 悠悠资源网亚洲青| 欧美高清在线精品一区| 欧美aⅴ一区二区三区视频| 亚洲精品一区二区三区福利| 亚洲黄色尤物视频| 欧美午夜在线观看| 亚洲一区二区三区久久| 亚洲欧美日韩国产成人| 国产一区视频网站| 欧美黄色免费| 欧美国产大片| 亚洲综合色婷婷| 欧美一区二区三区啪啪| 亚洲国产精品成人va在线观看| 亚洲激情视频在线观看| 国产精品qvod| 玖玖玖免费嫩草在线影院一区| 久久蜜臀精品av| 中文在线资源观看网站视频免费不卡| 亚洲私人影吧| 伊人夜夜躁av伊人久久| 亚洲精品看片| 狠狠88综合久久久久综合网| 亚洲黄网站在线观看| 国产精品手机视频| 久久影院午夜片一区| 欧美乱人伦中文字幕在线| 欧美一区二视频在线免费观看| 久久免费午夜影院| 亚洲一区一卡| 理论片一区二区在线| 亚洲永久在线观看| 欧美在线黄色| 亚洲国产精品嫩草影院| 蜜桃久久av一区| 欧美福利影院| 9l国产精品久久久久麻豆| 亚洲精品在线一区二区| 欧美亚洲成人网| 亚洲欧美中日韩| 久久国产精品色婷婷| 久久综合久久美利坚合众国| 亚洲欧美精品一区| 亚洲人午夜精品| 性色av一区二区三区| 亚洲最新中文字幕| 久久久天天操| 久久在线91| 亚洲激情小视频| 中文在线一区| 9国产精品视频| 久久精品亚洲国产奇米99| 在线视频精品一区| 久久天天躁夜夜躁狠狠躁2022| 午夜在线观看免费一区| 欧美日韩国产在线播放| 亚洲黄色在线视频| 亚洲乱码精品一二三四区日韩在线 | 久久av一区二区三区亚洲| 欧美日韩国产在线播放| 亚洲欧洲视频| 亚洲精品乱码久久久久久黑人| 久久精品国产亚洲一区二区三区| 欧美在线3区| 国产乱码精品一区二区三区忘忧草| 日韩视频亚洲视频| 中日韩在线视频| 欧美日本国产精品| 亚洲欧洲日韩综合二区| 91久久精品日日躁夜夜躁国产| 久久精品中文字幕免费mv| 久久欧美中文字幕| 精品不卡在线| 欧美成人精品不卡视频在线观看| 免费亚洲一区| 亚洲激情欧美激情| 欧美大秀在线观看| 91久久久亚洲精品| 亚洲午夜精品国产| 国产精品夜夜夜| 午夜精品区一区二区三| 久久天天躁狠狠躁夜夜爽蜜月| 国内伊人久久久久久网站视频| 中文国产成人精品| 欧美精品一区二区三区四区 | 久久精品123| 欧美黑人一区二区三区| 99热精品在线观看| 国产精品人人做人人爽| 欧美一级一区| 欧美风情在线| 亚洲少妇诱惑| 国产日韩欧美一区二区三区在线观看 | 久久午夜精品一区二区| 亚洲大片在线观看| 亚洲作爱视频| 国产精品女人网站| 久久久久网址| 亚洲人成亚洲人成在线观看| 欧美伊人久久久久久午夜久久久久| 国产欧美日本| 玖玖玖国产精品| 日韩特黄影片| 久久午夜色播影院免费高清| 亚洲精品日韩一| 国产啪精品视频| 欧美成ee人免费视频| 亚洲欧美日韩一区二区在线| 欧美成人首页| 欧美亚洲视频在线观看| 亚洲韩国青草视频| 国产精品久久999| 久久一区二区三区av| 亚洲视频在线观看网站| 免费成人美女女| 欧美一区2区三区4区公司二百| 亚洲第一久久影院| 国产精品视频导航| 欧美国产日本韩| 欧美中在线观看| 99精品国产在热久久| 久久精品一区二区三区不卡牛牛| 一区二区三区毛片| 在线观看日韩欧美| 国产日韩在线播放| 国产精品观看| 欧美另类videos死尸| 麻豆精品视频在线| 久久精品国产77777蜜臀| 在线亚洲欧美视频| 亚洲另类自拍| 最新69国产成人精品视频免费|