嚴(yán)以律己,寬以待人. 三思而后行. GMail/GTalk: yanglinbo#google.com; MSN/Email: tx7do#yahoo.com.cn; QQ: 3 0 3 3 9 6 9 2 0 .
使用引記數(shù),就算是再歷害的高手也難免會出錯(cuò)。而一但出錯(cuò)了,之后再去查問題可就相當(dāng)?shù)睦щy了。正如我曾經(jīng)看到,有一段代碼是這樣的:
m_spView->Release();m_spView->Release();m_spView->Release();
看到這段代碼,就知道引用計(jì)數(shù)出問題了。他想通過這種方式,把多出來的計(jì)數(shù)Release掉。但這么做能解決問題嗎?答案是不能,這樣的代碼還可能造成嚴(yán)重的穩(wěn)定性問題。解決引用計(jì)數(shù)問題,除了要了解引用計(jì)數(shù)規(guī)則外,我們還提昌要用智能指針。智能能幫助我們很好的處理引用計(jì)數(shù)問題。
在用VC開發(fā)應(yīng)用程序時(shí),有兩個(gè)引用計(jì)數(shù)類可供我們使用。_com_ptr_t與CComPtr,它們都能很好的幫助我們解決引用計(jì)數(shù)處理。但這兩個(gè)類還是有一點(diǎn)小小的區(qū)別,有的時(shí)候這一點(diǎn)區(qū)別也是致命的,因此我們必須清楚它們的差別。下面我羅列了它們之間的差別:
這些區(qū)別,導(dǎo)致了有些代碼不能同時(shí)應(yīng)用于兩個(gè)智能指針。
以上代碼會導(dǎo)致引用計(jì)數(shù)出錯(cuò),前面的9個(gè)View的引用計(jì)數(shù)并沒有Release。CComPtr<IView>的&運(yùn)算符,會返回IView**也就是CComPtr內(nèi)部成員的地址,但它不釋放原來的指針。而GetView又會修改指針,直接把原來的指針拋棄了。
這個(gè)代碼可以這樣改:
把指針作為循環(huán)的局部變量,這樣每次循環(huán)退出前spView都會被析構(gòu),最終調(diào)用Release。當(dāng)然還能這樣改:
_com_ptr_t的&運(yùn)算符會幫助我們把原來的指針Release掉,所以我們就不必?fù)?dān)心引用計(jì)數(shù)沒有釋放。
然我們使用的智能指針,就不要再去調(diào)AddRef或Release了。如果再去手工調(diào)用它們,就失去了智能指針的好處。CComPtr有一個(gè)非常巧妙的方法,禁止調(diào)用這兩個(gè)方法。它聲明了一個(gè)類_NoAddRefReleaseOnCComPtr,它的定義如下:
我們看到,里面就定義了兩個(gè)私有函數(shù)。AddRef與Release,它們重寫了IUnknown的這兩個(gè)方法,并且繼承自模板T。再來看段代碼:
我們看到的是CComPtr的”->”運(yùn)算符,它將內(nèi)部的指針強(qiáng)制轉(zhuǎn)換成_NoAddRefReleaseOnCComPtr<T>*。其中T是CComPtr的模板參數(shù),也就是接口指針類型。可以看出_NoAddRefReleaseOnCComPtr<T>繼承自接口類型,因此通過_NoAddRefReleaseOnCComPtr<T>*可以調(diào)用T的所有函數(shù)。前面我們看到NoAddRefReleaseOnCComPtr的兩個(gè)私用函數(shù),AddRef與Release,如果有誰想調(diào)用就會報(bào)編譯錯(cuò)誤。
_com_ptr_t有多個(gè)=運(yùn)算符版本,代碼如下:
其中template<typename _InterfaceType> _com_ptr_t& operator=(_InterfaceType* p)是一個(gè)模板函數(shù),接受任意類型的指針,函數(shù)內(nèi)部會調(diào)用傳入?yún)?shù)”p”的QueryInterface。
template<> _com_ptr_t& operator=(Interface* pInterface) throw()是模板函數(shù)的一個(gè)偏特化版本,接受_com_ptr_t模板參數(shù)中指定的指針類型。當(dāng)傳入的接口指針類型,與類模板指定的類型一樣時(shí)這個(gè)函數(shù)會被調(diào)用。它不需要做QueryInterface的調(diào)用,只是簡單的AddRef;
綜上所述,兩個(gè)智能指針在同一份代碼里混用,很可能導(dǎo)致不良后果。所以我認(rèn)為,最好不要在同一份代碼里混用。而這兩個(gè)指針,我很喜歡_com_ptr_t,它在許多方面明顯優(yōu)于CComPtr。
使用了智能指針,也并不是高枕無憂了。它還是給我們帶來了一些新的問題。
有一些第三方類庫設(shè)計(jì)的不合理,它在函數(shù)的返回值里返回接口指針。如下代碼就導(dǎo)會導(dǎo)致引用計(jì)數(shù)泄漏:
以上代碼,注意調(diào)用GetView的地方。IViewPtr是智能指針,它的=運(yùn)算符是會再調(diào)用AddRef而GetView里已經(jīng)調(diào)了一次AddRef了,這里多了一次AddRef。別問我GetView中為什么要AddRef,這是引用計(jì)數(shù)規(guī)則,不清楚請看《引用計(jì)數(shù)我不怕之引用計(jì)數(shù)規(guī)則》。
解決這個(gè)問題的方法就是用Attach函數(shù)
也許是有人寫了Attach,而其它人不明白Attach的意思,結(jié)果寫出了這樣的代碼。
根據(jù)引用計(jì)數(shù)規(guī)則,將指針保存為副本,必須AddRef。但是這個(gè)例子里沒有這么干,結(jié)果m_spView變成了野指針。
前面我們看到的GetView很簡單,但是下面我們要做一別的事情,于是要用智能指針。
表面看來沒什么問題,但在函數(shù)返回后,智能指針又會調(diào)用一次Release。要解決這個(gè)問題,可以調(diào)用Detach。
Detach還是會被亂用,看到這樣的代碼還真是哭笑不得。
這段代碼能導(dǎo)致兩個(gè)問題
泄漏是由于Detach返回IView*,并不會Release,而spView又會再調(diào)用一次AddRef。智能指針的Detach是會把自己設(shè)成空的,否則還叫什么Detach。
使用智能指針,是解決引用計(jì)數(shù)問題最好的辦法。不要因?yàn)橛弥悄苤羔?,會引入新的問題,而放棄使用它。只要花心思搞清楚智能指針的不同點(diǎn),使用時(shí)注意一些細(xì)節(jié)問題,使用起來應(yīng)該會變的非常輕松。
posted on 2011-01-18 16:14 楊粼波 閱讀(1512) 評論(0) 編輯 收藏 引用
Powered by: C++博客 Copyright © 楊粼波