• <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>

            huaxiazhihuo

             

            私有繼承小討論

            大家都知道,大C++里面可以私有繼承,之后基類(lèi)的一切,在子類(lèi)中就成為private的了,不對(duì)外開(kāi)放了。現(xiàn)在流行接口,組合優(yōu)化繼承,所以private繼承這玩意,日漸式微,很久以前就很少使用了,嗯,不要說(shuō)private,就算是大c++,也是江河日下。不過(guò),存在即合理,c++語(yǔ)法里面的任何東西,都有其價(jià)值,平時(shí)可以用不到,但是關(guān)鍵時(shí)刻用一下,確實(shí)很方便,當(dāng)然多數(shù)情況下,也可以其他途徑來(lái)完成,但是,就是沒(méi)那么舒服。

            廢話就不說(shuō)了,直入正題吧。

            假設(shè),現(xiàn)在有接口,假設(shè)是IUnknown,里面有那三個(gè)著名的純虛函數(shù),QueryInterface, AddRef, Release,好像是這三個(gè)哥倆。

            然后,有一個(gè)類(lèi),就叫ClassA,實(shí)現(xiàn)了IUnknown接口,其實(shí)就是繼承IUnknown,也就是說(shuō),重寫(xiě)了那三個(gè)純虛函數(shù)。此外,ClassA還有一大堆自己的東西,比如public的字段或者成員函數(shù)。

            現(xiàn)在,有ClassB,想基于ClassA來(lái)做一些事情,但是又不想讓用戶看到ClassA里面那些亂七八糟的玩意,因此,這種情況下,用private似乎很合適。代碼如下:

                     struct IUnknown

                     {

                     public:

                                        virtual HRESULT QueryInterface(REFIID riid,void** ppvObject) = 0;

                                        virtual ULONG AddRef() = 0;

                                        virtual ULONG Release() = 0;

                     };

                     struct ClassA : IUnknown

                     {

                               virtual HRESULT QueryInterface(REFIID riid, void** ppvObject) override { ... }

                               virtual ULONG AddRef() override { ... }

                               virtual ULONG Release() override { ... }

                               ...

                     };

                     struct ClassB : private ClassA

                     {

                               ...

                     };

            這里,內(nèi)存的使用上非常緊湊,可以說(shuō),沒(méi)有多余的地方。但是,這里的private,不僅僅會(huì)private ClassA的一切,就連IUnknown也被private,這有時(shí)候就不符合要求了,因?yàn)檫@里意圖是,private ClassA,但是又想public IUnknown,也就是說(shuō),對(duì)外界來(lái)說(shuō),ClassB不是ClassA,雖然其內(nèi)部基于ClassA實(shí)現(xiàn),但是,又希望ClassBIUnknown。對(duì)此,有幾種解決做法,但是都不能讓人滿意。

            方法1、讓ClassB再次實(shí)現(xiàn)IUnknown接口,如下所示:

                     struct ClassB : private ClassA, public IUnknown

                     {

                               virtual HRESULT QueryInterface(REFIID riid, void** ppvObject) override { ... }

                               virtual ULONG AddRef() override { ... }

                               virtual ULONG Release() override { ... }

                     };

            其好處是,ClassB的實(shí)例可以無(wú)縫用于IUnknown的一切場(chǎng)合,不管是引用或者指針,constconst。但是,代價(jià)也是很大的,首先要針對(duì)IUnknown的每個(gè)虛函數(shù),都要一一手寫(xiě),再次轉(zhuǎn)發(fā)給private的基類(lèi),其次,ClassBClassA多了一個(gè)虛函數(shù)表指針,大小就比原來(lái)多了一個(gè)指針的大小,這就不是零懲罰了,這是最不該。

            方法2,還是保持私有繼承,再在ClassB中添加幾個(gè)函數(shù),用以返回IUnknown,代碼如下

                     struct ClassB : private ClassA

                     {

                               //也可以using ClassA的三個(gè)IUnknown里面的函數(shù)

                               const IUnknown* GetUnknown()const { return this; }

                               IUnknown* GetUnknown()const { return this; }

                     };

            避開(kāi)了方法1的不足,但是就不能無(wú)縫用于IUnknown下,每次使用必須調(diào)用一下GetUnknown(),對(duì)于引用的情況下,還必須加多一個(gè)星號(hào)*,也是挺不方便的。對(duì)了,這里就算添加了類(lèi)型函數(shù)重載,也即是operator IUnknown,編譯器也拒絕將ClassB無(wú)縫轉(zhuǎn)換成IUnknown

            方法3,用包含,不用私有繼承。如下:

                     struct ClassB

                     {

                               ClassA mA;

                               operator const IUnknown&()const { return *this; }

                               operator IUnknown&() { return *this; }

                     };

            這樣子,ClassB的實(shí)例可以無(wú)縫用于IUnknown引用下的情況。對(duì)于指針的話,可以仿造方法2那樣子,寫(xiě)兩個(gè)函數(shù)進(jìn)行調(diào)用。貌似綜合起來(lái),方法3的整體分?jǐn)?shù)最高。

            就個(gè)人而言,更偏向于,直接就讓ClassB public繼承ClassA好了,少了那么多鬼怪,雖然出現(xiàn)很多不必要的函數(shù),其實(shí)也沒(méi)什么不好。

            posted on 2017-12-13 15:17 華夏之火 閱讀(1223) 評(píng)論(2)  編輯 收藏 引用 所屬分類(lèi): c++技術(shù)探討

            評(píng)論

            # re: 私有繼承小討論 2017-12-14 09:21 ccsdu2009

            C++江河日下?  回復(fù)  更多評(píng)論   

            # re: 私有繼承小討論 2018-01-10 09:20 天下

            不想要完美的解決方案,任何語(yǔ)言都不是完美的.

            完美主義的追求大多數(shù)是坑自己,浪費(fèi)生命!  回復(fù)  更多評(píng)論   

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            留言簿(6)

            隨筆分類(lèi)

            隨筆檔案

            搜索

            積分與排名

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            中文无码久久精品| 精品免费久久久久国产一区| 九九精品久久久久久噜噜| 国产美女亚洲精品久久久综合| 久久综合久久美利坚合众国| 热re99久久6国产精品免费| 夜夜亚洲天天久久| 亚洲国产精品综合久久一线| 午夜精品久久久久久久| 狠狠人妻久久久久久综合蜜桃| 久久乐国产综合亚洲精品| 狠狠色丁香久久综合五月| 中文字幕无码久久久| 国产精品视频久久| 亚洲狠狠婷婷综合久久蜜芽| 国产午夜精品理论片久久| 日韩AV无码久久一区二区| 久久无码一区二区三区少妇| 国产69精品久久久久777| 99久久无色码中文字幕人妻| 欧美亚洲另类久久综合婷婷| 亚洲国产二区三区久久| 亚洲日韩中文无码久久| 久久婷婷是五月综合色狠狠| 国产免费久久精品丫丫| 久久香蕉国产线看观看99| 无码伊人66久久大杳蕉网站谷歌 | 亚洲精品乱码久久久久久不卡| 色婷婷综合久久久久中文| 亚洲美日韩Av中文字幕无码久久久妻妇 | 久久久久免费看成人影片| 久久国产AVJUST麻豆| 亚洲色欲久久久久综合网| 精品免费久久久久国产一区| 国内精品久久国产大陆| 久久精品夜夜夜夜夜久久| 色综合久久中文字幕无码| 77777亚洲午夜久久多人| 中文无码久久精品| 东京热TOKYO综合久久精品| 久久精品国产精品亚洲毛片 |