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

<2009年5月>
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456

統計

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

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

相冊

搜索

  •  

最新評論

閱讀排行榜

評論排行榜

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

C實現COM接口系列1中實現的com接口IFoo與使用它的客戶耦合在一起,沒有實現在各自分離的模塊,因此不符合模塊化編程思想。本期添加類廠支持,以使接口的實現與接口的使用相分離。

---------------------------------------------------
類廠的作用到底是什么?
將接口的實現與客戶使用分離開來嗎?

不盡然。使用CoCreateInstance,客戶可以完全不必知道類廠的存在,而創建組件,獲取組件實現的接口并使用。

即COM庫可以完全拋開類廠的概念,而是提供一個這樣的函數原型:
CoCreateObject(REFID rclsid,...,REFID riid,void **ppItf);
用戶在調用的時候可以對riid提供IID_Unknown或者特定于該對象的一個接口,直接獲取該對象的IUnknown或特定的接口指針。

可以看到,這正是CoCreateInstance所作的事情。

1 類廠提供了間接創建類對象的方式:用戶可以先獲取并持有類廠接口指針,通過該指針所指向的類廠接口創建類對象。適用于需要創建多個(或重復創建)類對象的地方,減少了每次都要定位對象庫并把對象庫裝入內存的開銷。
2 類廠提供了保證組件庫留在內存不被卸載出去的另一種方法:類廠接口函數LockServer。組件庫維護一個庫范圍計數器,只有該計數器為0時,組件庫才允許自己被卸載出內存。(與此相對,引用計數是類對象范圍的,通過該類實現的各個接口來維護。如果一個類對象的引用計數達到0,那么該對象占有的內存就被釋放,該對象上的接口指針也不再有效。)
除了調用LockServer鎖定組件庫以外,當創建的組件個數大于0時,組件庫也不能被卸載。也可以說,調用一次LockServer()的作用相當于創建了一個組件。

-----------------------------------------------------------------------
客戶一側:
1 使用一個接口需要知道哪些信息?
備選:
接口IID
類對象(類廠)CLSID(或ProgID)
接口函數原型(參數個數,類型,返回值)
實現接口組件的線程模型(進程內、進程外、遠程)?
類型庫typelib信息?

服務一側:
2 實現一個組件和接口以供客戶調用,需要提供哪些東西?
備選:
所有客戶使用組件和接口所需的內容
額外的還有:


--------------------------------------------------------------------
為dll添加.def文件與直接在需要導出的函數定義處指定_declspec( dllexport )有區別嗎?如果有是什么區別?

我發現在outdll.c中這樣指定:
__declspec( dllexport ) HRESULT DllGetClassObject (REFCLSID rclsid, REFIID riid, void **ppv)
會產生編譯錯誤:
1>------ Build started: Project: outside, Configuration: Debug Win32 ------
1>Compiling...
1>outdll.c
1>d:\outside-cf\outside\outdll.c(19) : error C2375: 'DllGetClassObject' : redefinition; different linkage
1>        c:\program files\microsoft visual studio 8\vc\platformsdk\include\objbase.h(833) : see declaration of 'DllGetClassObject'
1>Build log was saved at "file://d:\outside-cf\outside\Debug\BuildLog.htm"
1>outside - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

c2375的解釋意思是出錯的函數使用的鏈接指示符與之前聲明的不同。
Compiler Error C2375
'function' : redefinition; different linkage

The function is already declared with a different linkage specifier.

objbase.h中聲明了DllGetClassObject()函數:
STDAPI  DllGetClassObject(IN REFCLSID rclsid, IN REFIID riid, OUT LPVOID FAR* ppv);

而使用.def文件就沒有問題。

-----------------------------------------------------------------------------
初次執行結果:

問題就是總有一個分配的內存沒有釋放:

 


根據打印出來的內存地址可以判斷,應該是先創建的類廠對象的內存沒有釋放。
檢查代碼,main()中并沒有忘記調用Release(pCF)釋放類廠對象。打印Release(pCF)的返回值,發現是1,即在類廠接口指針上少調用了一次Release,那么,究竟是哪里少的呢?

main()函數中有關類廠對象引用計數的地方就是CoGetClassObject和Release(CreateInstance跟類廠自己的引用計數無關),這是一對增加引用計數和減少引用計數的對應操作,所以,main()中應該沒有問題。

那么,就只有創建類廠對象的時候了。下面看一下類廠對象是如何創建的。
首先,main調用CoGetClassObject,該函數就調用dll中的DllGetClassObject。由于是第一次調用(不考慮其他客戶使用該dll的情況),程序執行到CreateClassFactory(...),該函數執行完后,類廠對象的引用計數是1。

由于創建成功,因此繼續向下執行到QueryInterface,此時,類廠對象的引用計數變成了2。然后,DllGetClassObject返回,com庫函數CoGetClassObject也應該返回。注意,此時的類廠對象引用計數已經是2了!

因此,問題就出在這里。main調用一次CoGetClassObject后,類廠對象的引用計數是2,而不是我想向中的1。于是,后面調用一次Release也就當然無法釋放掉類場對象了。

 

 

 1 HRESULT DllGetClassObject (REFCLSID rclsid, REFIID riid, void **ppv)
 2 {
 3     *ppv = 0;
 4     if (IsEqualCLSID (rclsid, &CLSID_Outside))
 5     {
 6 
 7         if (!vpcfOutside)
 8 
 9         {
10 
11             HRESULT hr = CreateClassFactory (&CLSID_Outside, CreateOutside,
12                                              &IID_IClassFactory, &vpcfOutside);
13 
14                 if (hr != NOERROR)
15 
16                     return hr;
17         }
18 
19         return QueryInterface (vpcfOutside, riid, ppv);
20 
21     }
22 
23     return E_FAIL;
24 }

 

 


找到了原因,改正就很容易了。這里我覺得需要把DllGetClassObject作如下修改:

 1 HRESULT DllGetClassObject (REFCLSID rclsid, REFIID riid, void **ppv)
 2 {
 3     *ppv = 0;
 4     if (IsEqualCLSID (rclsid, &CLSID_Outside))
 5     {
 6 
 7         if (!vpcfOutside)
 8 
 9         {
10 
11             HRESULT hr = CreateClassFactory (&CLSID_Outside, CreateOutside,
12                                              &IID_IClassFactory, &vpcfOutside);
13 
14                 if (hr != NOERROR)
15 
16                     return hr;
17 
18     if(IsEqualIID(riid,&IID_IClassFactory))
19     {
20      *ppv = vpcfOutside;// Set *ppv to vpcfOutside directly instead of QueryInterface if first time creation
21      return NOERROR;
22     }
23     else
24     {
25      Release(vpcfOutside);// Any interface requested (riid) other than IID_ClassFactory and IID_Unknown not support by class factory,
26                           // call Release to free the memory.
27      return E_FAIL;
28     }
29 
30         }
31 
32         return QueryInterface (vpcfOutside, riid, ppv);
33 
34     }
35 
36     return E_FAIL;
37 }

 

修改后在執行,內存都正常釋放了。

-------------------------------------------------------------------------------------------
CreateClassFactory代碼說明

 1 HRESULT CreateClassFactory (REFCLSID rclsid,
 2     HRESULT (*pfnCreate)(IUnknown *, REFIID, void **), 
 3     REFIID riid, void **ppv)
 4 {
 5     ClassFactory *this;
 6     HRESULT hr;
 7     
 8     *ppv = 0;
 9     if (hr = Alloc (sizeof (ClassFactory), &this))
10     return hr;
11 
12     this->icf.lpVtbl = &vtblClassFactory;
13     this->cRef = 1;  // After this call, cRef==1
14 
15     this->pfnCreate = pfnCreate;
16     
17     hr = QueryInterface (&this->icf, riid, ppv);  // After this call, cRef==2
18     Release (&this->icf);  // Corresponds to "this->cRef = 1", ater this call, cRef==1
19 
20     return hr;
21 }

 

可以看到,兩行代碼的效果是對引用計數增1及減1,這兩行代碼執行后,對引用計數的影響互相抵消,等于沒有改變引用計數。那么,把這兩行同時注釋掉,是不是可以呢?
我的回答是:在本例中可以。因為這兩行代碼之間的QueryInterface總是可以執行成功的(因為是用IDD_ClassFactory來調用該函數的)。所以,即便把這兩行代碼同時注釋掉,CreateClassFactory執行結束后,類廠對象的引用計數也增了1,以后調用Release就可以釋放掉類廠對象占用的內存。
但是,如果CFQueryInterface的代碼編寫中除了錯誤,比如,像這樣寫:

 1 static HRESULT CFQueryInterface (IClassFactory *pcf, REFIID riid, void **ppv)
 2 {
 3     ClassFactory *this = IMPL (ClassFactory, icf, pcf);
 4 
 5     if (IsEqualIID (riid, &IID_IUnknown) ||
 6 //            IsEqualIID (riid, &IID_IClassFactory))   // Comment out this condition to create an error
 7         *ppv = &this->icf;
 8     else
 9     {
10         *ppv = 0;
11         return E_NOINTERFACE;
12     }
13 
14     AddRef ((IClassFactory *)*ppv);
15 
16     return NOERROR;
17 }


那么,這兩行代碼之間的QueryInterface就會執行出錯,那么類廠對象占用的內存就永遠沒有機會釋放了。
也就是說,AddRef和Release雖然在作用上對引用計數來說相互抵消,但Release函數提供了釋放對象內存的機會(當引用計數為0時),如果不成對的調用他們,也就失去了管理對象內存(釋放對象占用的內存)的機會。

---------------------------------------------------------------------------
組件庫outside文件說明:
 IFoo.h      IFoo接口聲明
 outside.c   組件對象、IFoo接口實現
 cf.c        類廠對象、IClassFactory接口實現
 outdll.c    組件庫導出函數實現
 outside.def 組件庫模塊定義文件,導出函數聲明
 outside.reg 組件庫注冊文件

----------------------------------------------------------------------------
源碼: outside-cf

posted on 2009-05-11 16:28 小蔥蘸醬 閱讀(1163) 評論(0)  編輯 收藏 引用 所屬分類: 編碼點滴

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            国产精品国产精品| 亚洲欧美中文日韩在线| 亚洲欧美久久| 午夜精品www| 欧美一区二区成人| 欧美中文字幕久久| 可以免费看不卡的av网站| 嫩草成人www欧美| 亚洲福利视频二区| 亚洲精品久久久久久久久久久久| 91久久精品一区二区三区| 一本一道久久综合狠狠老精东影业 | 亚洲欧美日韩高清| 性伦欧美刺激片在线观看| 久久精品视频在线| 亚洲国产精品一区二区久| 日韩西西人体444www| 亚洲永久视频| 欧美18av| 国产精品国产精品国产专区不蜜| 黄色在线一区| 在线一区二区日韩| 久久综合狠狠综合久久综青草 | 国产精品国产三级国产专播品爱网| 国产精品视频免费在线观看| 韩国精品主播一区二区在线观看| 亚洲人成艺术| 久久大香伊蕉在人线观看热2| 欧美成人激情在线| 午夜精品久久久久久久| 国产欧美日韩另类一区| 久久精品30| 久久xxxx| 亚洲精品日本| 美国十次成人| 国产一区香蕉久久| 午夜在线精品偷拍| 亚洲区在线播放| 久久艳片www.17c.com| 国产精品一区二区你懂得 | 亚洲国产精品一区二区第四页av| 亚洲综合大片69999| 欧美激情片在线观看| 欧美在线看片| 国产三级精品在线不卡| 亚洲欧美在线免费观看| 亚洲精品色婷婷福利天堂| 久久综合网络一区二区| 国产一区av在线| 欧美一激情一区二区三区| 9色porny自拍视频一区二区| 欧美成人精品1314www| 亚洲高清毛片| 欧美福利视频一区| 久久久噜噜噜久久人人看| 国内精品福利| 久久天天狠狠| 久久久久国产精品人| 国产一区二区三区自拍| 久久九九精品99国产精品| 午夜天堂精品久久久久| 国产视频在线观看一区| 久久精品国产2020观看福利| 亚洲欧美日韩中文视频| 国产精品永久免费| 欧美在线黄色| 欧美一区三区二区在线观看| 国产亚洲毛片在线| 老司机精品视频一区二区三区| 久久久国际精品| 在线观看亚洲精品视频| 欧美高清不卡| 欧美日韩视频| 午夜欧美精品| 久久国产精品99久久久久久老狼| 国产综合亚洲精品一区二| 欧美aa国产视频| 欧美激情麻豆| 欧美国产精品一区| 亚洲伊人观看| 性欧美大战久久久久久久久| 激情视频一区| 亚洲精品综合精品自拍| 国产精品一二一区| 农夫在线精品视频免费观看| 欧美另类69精品久久久久9999| 亚洲欧美日韩国产综合| 久久国产精彩视频| 亚洲最新色图| 一区二区三区黄色| 国产午夜亚洲精品理论片色戒| 亚洲欧美中文字幕| 欧美在线观看日本一区| 亚洲高清在线观看| 一区二区三区国产精华| 国产一区二区无遮挡| 91久久极品少妇xxxxⅹ软件| 国产精品久久久久久久一区探花| 久久人人97超碰精品888| 欧美精品导航| 久久久无码精品亚洲日韩按摩| 欧美成人第一页| 久久精品国产精品| 欧美日韩一区自拍| 欧美1区2区3区| 国产精品日本欧美一区二区三区| 欧美 日韩 国产一区二区在线视频 | 亚洲夜晚福利在线观看| 久久se精品一区精品二区| 日韩性生活视频| 久久精品亚洲一区| 欧美一区二区黄| 欧美日韩在线播放三区| 欧美风情在线观看| 国产原创一区二区| 亚洲与欧洲av电影| 一区二区欧美国产| 蜜臀久久99精品久久久久久9| 性欧美video另类hd性玩具| 欧美理论电影在线播放| 亚洲电影激情视频网站| 国产综合网站| 翔田千里一区二区| 亚洲欧美日韩国产精品 | 久久精品亚洲一区二区三区浴池| 亚洲一区亚洲| 欧美日韩的一区二区| 欧美韩日一区二区| 在线国产亚洲欧美| 久久免费黄色| 免费欧美在线视频| 亚洲高清毛片| 久久资源av| 蜜桃久久av一区| 在线看日韩av| 欧美fxxxxxx另类| 亚洲国产第一| 日韩天堂在线观看| 香蕉久久a毛片| 国产精品外国| 欧美一区二区精品久久911| 久久成人精品无人区| 国产啪精品视频| 久久国产一二区| 欧美成人免费va影院高清| 在线欧美一区| 欧美伦理91i| 这里只有精品丝袜| 欧美在线|欧美| 黄色成人在线网址| 欧美3dxxxxhd| 在线一区视频| 欧美激情亚洲| 欧美视频在线一区二区三区| 欧美激情中文不卡| 艳女tv在线观看国产一区| 欧美韩日一区二区| 日韩视频在线观看| 香蕉成人久久| 影音先锋成人资源站| 欧美激情在线有限公司| 99精品久久久| 久久久久国产精品一区三寸| 亚洲电影网站| 欧美日韩在线直播| 久久精品人人做人人爽电影蜜月 | 国产一区二区三区久久久| 久久久久久一区| 亚洲精品美女在线| 欧美一区二区免费视频| 在线播放精品| 欧美视频一区二区三区| 欧美一区二区女人| 亚洲精品一区二| 久久久一本精品99久久精品66| 亚洲黑丝在线| 国产精品尤物| 欧美日韩精品欧美日韩精品一| 亚洲一区二区久久| 欧美国产日韩一区二区在线观看| 亚洲永久字幕| 亚洲欧洲精品一区二区| 国产精品一区免费在线观看| 你懂的国产精品| 午夜一区在线| 中国日韩欧美久久久久久久久| 裸体歌舞表演一区二区| 亚洲欧美综合另类中字| 99国产成+人+综合+亚洲欧美| 国产三级精品在线不卡| 欧美日韩综合另类| 欧美国产日本韩| 久久成人免费| 亚洲在线中文字幕| 日韩视频在线免费观看| 欧美风情在线观看| 美女视频黄免费的久久| 久久久久综合网| 久久成人精品电影| 香蕉成人伊视频在线观看|