• <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>
            春暖花開
            雪化了,花開了,春天來(lái)了
            posts - 149,comments - 125,trackbacks - 0
            在園里轉(zhuǎn),看到好文章,摘抄過(guò)來(lái)。
            鏈接:
            http://m.shnenglu.com/franksunny/archive/2008/10/16/64168.html


            原文:

            為什么要引入虛擬繼承?

            虛擬繼承在一般的應(yīng)用中很少用到,所以也往往被忽視,這也主要是因?yàn)樵?/span>C++中,多重繼承是不推薦的,也并不常用,而一旦離開了多重繼承,虛擬繼承就完全失去了存在的必要(因?yàn)檫@樣只會(huì)降低效率和占用更多的空間,關(guān)于這一點(diǎn),我自己還沒有太多深刻的理解,有興趣的可以看網(wǎng)絡(luò)上白楊的作品RTTI、虛函數(shù)和虛類的開銷分析及使用指導(dǎo),說(shuō)實(shí)話我目前還沒看得很明白,高人可以指點(diǎn)下我)。

            以下面的一個(gè)例子為例:

            #include <iostream.h>

            #include <memory.h>

            class CA

            {

                int k; //如果基類沒有數(shù)據(jù)成員,則在這里多重繼承編譯不會(huì)出現(xiàn)二義性

            public:

                void f() {cout << "CA::f" << endl;}

            };

             

            class CB : public CA

            {

            };

             

            class CC : public CA

            {

            };

             

            class CD : public CB, public CC

            {

            };

             

            void main()

            {

                CD d;

                d.f();

            }

            當(dāng)編譯上述代碼時(shí),我們會(huì)收到如下的錯(cuò)誤提示:

            error C2385: 'CD::f' is ambiguous

            即編譯器無(wú)法確定你在d.f()中要調(diào)用的函數(shù)f到底是哪一個(gè)。這里可能會(huì)讓人覺得有些奇怪,命名只定義了一個(gè)CA::f,既然大家都派生自CA,那自然就是調(diào)用的CA::f,為什么還無(wú)法確定呢?

            這是因?yàn)?span>編譯器在進(jìn)行編譯的時(shí)候,需要確定子類的函數(shù)定義,如CA::f是確定的,那么在編譯CBCC時(shí)還需要在編譯器的語(yǔ)法樹中生成CB::fCC::f等標(biāo)識(shí),那么,在編譯CD的時(shí)候,由于CBCC都有一個(gè)函數(shù)f,此時(shí),編譯器將試圖生成這兩個(gè)CD::f標(biāo)識(shí),顯然這時(shí)就要報(bào)錯(cuò)了。(當(dāng)我們不使用CD::f的時(shí)候,以上標(biāo)識(shí)都不會(huì)生成,所以,如果去掉d.f()一句,程序?qū)㈨樌ㄟ^(guò)編譯

             

            要解決這個(gè)問(wèn)題,有兩個(gè)方法:

            1、重載函數(shù)f():此時(shí)由于我們明確定義了CD::f,編譯器檢查到CD::f()調(diào)用時(shí)就無(wú)需再像上面一樣去逐級(jí)生成CD::f標(biāo)識(shí)了;

            此時(shí)CD的元素結(jié)構(gòu)如下:

            |CB(CA)|

            |CC(CA)|

            故此時(shí)的sizeof(CD) = 8;CBCC各有一個(gè)元素k

            2、使用虛擬繼承:虛擬繼承又稱作共享繼承,這種共享其實(shí)也是編譯期間實(shí)現(xiàn)的,當(dāng)使用虛擬繼承時(shí),上面的程序?qū)⒆兂上旅娴男问剑?/span>

            #include <iostream.h>

            #include <memory.h>

            class CA

            {

                int k;

            public:

                void f() {cout << "CA::f" << endl;}

            };

             

            class CB : virtual public CA //也有一種寫法是class CB : public virtual CA

            {                       //實(shí)際上這兩種方法都可以

            };

             

            class CC : virtual public CA

            {

            };

             

            class CD : public CB, public CC

            {

            };

             

            void main()

            {

                CD d;

                d.f();

            }

            此時(shí),當(dāng)編譯器確定d.f()調(diào)用的具體含義時(shí),將生成如下的CD結(jié)構(gòu):

            |CB|

            |CC|

            |CA|

            同時(shí),在CBCC中都分別包含了一個(gè)指向CA的虛基類指針列表vbptrvirtual base table pointer),其中記錄的是從CBCC的元素到CA的元素之間的偏移量。此時(shí),不會(huì)生成各子類的函數(shù)f標(biāo)識(shí),除非子類重載了該函數(shù),從而達(dá)到“共享”的目的(這里的具體內(nèi)存布局,可以參看鉆石型繼承內(nèi)存布局,在白楊的那篇文章中也有)。

            也正因此,此時(shí)的sizeof(CD) = 12(兩個(gè)vbptr + sizoef(int);

             

            另注:

            如果CBCC中各定義一個(gè)int型變量,則sizeof(CD)就變成20(兩個(gè)vbptr + 3個(gè)sizoef(int)

            如果CA中添加一個(gè)virtual void f1(){}sizeof(CD) = 16(兩個(gè)vbptr + sizoef(int)+vptr;

            再添加virtual void f2(){}sizeof(CD) = 16不變。原因如下所示:帶有虛函數(shù)的類,其內(nèi)存布局上包含一個(gè)指向虛函數(shù)列表的指針(vptr),這跟有幾個(gè)虛函數(shù)無(wú)關(guān)。

            以上內(nèi)容涉及到類對(duì)象內(nèi)存布局問(wèn)題,本人還難以做過(guò)多展開,先貼這么多,本篇文章只是考慮對(duì)于虛擬繼承進(jìn)行入門,至于效率、應(yīng)用等未作展開。本文在網(wǎng)上文章基礎(chǔ)上修改了下而得此篇,原文載于http://blog.csdn.net/billdavid/archive/2004/06/23/24317.aspx

            另外關(guān)于虛繼承和虛基類的討論,博客園有篇文章《虛繼承與虛基類的本質(zhì)》,總結(jié)得更為詳細(xì)一點(diǎn)。

            posted on 2008-10-16 21:48 Sandy 閱讀(416) 評(píng)論(1)  編輯 收藏 引用 所屬分類: C++

            FeedBack:
            # re: 虛擬繼承入門
            2008-10-16 21:58 | SpringSnow
            不錯(cuò),學(xué)習(xí)了。  回復(fù)  更多評(píng)論
              
            99久久免费国产精品特黄| 久久九九久精品国产免费直播| 2021国产成人精品久久| 久久精品国产亚洲av日韩| 久久国产精品99精品国产987| 中文字幕无码久久久| 国产精品久久久久蜜芽| 麻豆久久久9性大片| 久久亚洲美女精品国产精品| 久久国产精品成人免费| 久久精品国产亚洲av瑜伽| 亚洲色欲久久久综合网东京热| 精品免费tv久久久久久久| 精品国产综合区久久久久久 | 午夜精品久久影院蜜桃| 久久精品青青草原伊人| 青青国产成人久久91网| 综合人妻久久一区二区精品| 精品免费久久久久国产一区 | 色噜噜狠狠先锋影音久久| 欧美久久久久久午夜精品| 欧美一区二区久久精品| 日本三级久久网| 少妇无套内谢久久久久| 7国产欧美日韩综合天堂中文久久久久| 久久亚洲AV无码精品色午夜| 免费观看久久精彩视频| 久久亚洲AV无码精品色午夜| 国产L精品国产亚洲区久久| 久久精品中文闷骚内射| 思思久久99热只有频精品66| 亚洲国产成人精品久久久国产成人一区二区三区综 | 久久AAAA片一区二区| 久久婷婷国产综合精品| 国产精品一区二区久久精品涩爱| 99久久成人国产精品免费| 亚洲а∨天堂久久精品9966| 久久99精品九九九久久婷婷 | 久久高清一级毛片| 国产精品久久久久aaaa| 国产韩国精品一区二区三区久久|