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

            Note of Justin

            關(guān)于工作和讀書的筆記

              C++博客 :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
              47 Posts :: 0 Stories :: 45 Comments :: 0 Trackbacks

            留言簿(14)

            搜索

            •  

            積分與排名

            • 積分 - 52498
            • 排名 - 433

            最新評論

            閱讀排行榜

            評論排行榜

            [原創(chuàng)文章歡迎轉(zhuǎn)載,但請保留作者信息]

            Justin 于 2010-01-21

            Scott 開篇就直接說開了: C++ 陣營中關(guān)于多重繼承 (Multiple Inheritance, MI) 分成了兩派,一派認(rèn)為多重繼承比單一繼承好,另外一邊則認(rèn)為弊大于利。

            所以本課的內(nèi)容就是說說 MI 的優(yōu)與劣。

            MI 的第一個問題就是名字沖突, 最經(jīng)典的例子就是鉆石問題 (diamond problem)。
            設(shè)想 A 中有一個函數(shù)叫做 GetName() , B C 中都將有這一函數(shù)成員,這個時候 D :: GetName() 的真正實現(xiàn)是來自 B 的還是 C 的呢?二義性出現(xiàn)了 (ambiguity) 。

            不過如果真的發(fā)生了這種情況,要解決的方法也不是沒有,可以這樣做:

            D?d;
            d.B::GetName();?
            //Calling?B's?implementation

            嗯,很容易理解。

            另外一個高階一點的方法叫做虛繼承 (virtual inheritance) 。對于在虛擬繼承中的父類,其中的成員都保證不會在后面的子類中出現(xiàn)二義現(xiàn)象 (ambiguity) 。似乎是專門為了 MI 才整出來的,汗 ……

            例子還是已前面的鉆石問題:

            class?A
            {
            ???
            public:
            ??????
            void?GetName();
            //..
            };

            class?B?:?virtual?public?A
            {
            //..
            };

            class?C?:?virtual?public?A
            {
            //..
            };

            class?D?:?public?B,?public?C
            {
            //..
            }

            D?d;
            d.GetName();?
            //there?is?no?ambiguity?here.

            但是虛繼承不是沒有代價的,大師說這種技術(shù)會使得最終代碼變得更大,訪問虛擬繼承中的父類成員也會變得更慢一些。

            這個也不難理解。和空間換時間一樣,和不給牛吃草牛就不干活一樣。 ( 另外的一個代價我還沒能完全理解透徹:書上說因為虛繼承中基類的初始化是由繼承關(guān)系中最底層的子類負(fù)責(zé)的,因此對于這些最底下的 嫡孫 類來說,就不是那么方便了 )

            于是大師建議只有在必要的時候才使用虛繼承,而在虛繼承中的基類里也不要放置數(shù)據(jù)成員,這樣就不用擔(dān)心初始化的問題了。

            不過存在就是合理,還是有需要用到 MI 的時候。一個在書中提到的使用 MI 的情形是:當(dāng)需要從一個類 AClass 中繼承接口,又需要從另外一個類 BClass 中繼承實現(xiàn)細(xì)節(jié)時,就可以考慮在公有繼承 AClass 的同時又私有繼承 BClass 。道理大致就是這樣,就不編造程序畫蛇添足了。

            總結(jié)一下: MI SI(Single Inheritance) 要復(fù)雜容易出錯 ( 比如說鉆石問題 ) ,即使可以用虛繼承來解決鉆石問題,但是其帶來的代碼體積增大,訪問效率下降以及初始化問題還是不能忽視的。最后話說回來,需要用到 MI 的時候,小心點用便是 @# %

            【參考】 http://en.wikipedia.org/wiki/Virtual_inheritance

            posted on 2010-03-15 09:18 Justin.H 閱讀(381) 評論(0)  編輯 收藏 引用 所屬分類: Effective C++ 炒冷飯
            久久久免费观成人影院| 久久天天躁狠狠躁夜夜2020老熟妇| 色欲综合久久躁天天躁| 香蕉99久久国产综合精品宅男自 | 91久久精品无码一区二区毛片| 大伊人青草狠狠久久| 久久丝袜精品中文字幕| 伊人色综合久久天天人手人婷| 久久久久亚洲av无码专区喷水 | 久久午夜无码鲁丝片| 久久91亚洲人成电影网站| 亚洲精品久久久www| 久久亚洲AV成人无码国产| 久久久久国产一区二区| 99久久99这里只有免费费精品| 久久有码中文字幕| 女人香蕉久久**毛片精品| 亚洲精品国产字幕久久不卡| 国产香蕉97碰碰久久人人| 午夜人妻久久久久久久久| 亚洲国产日韩欧美久久| 99久久精品免费国产大片| 欧美va久久久噜噜噜久久| 久久99久国产麻精品66| 亚洲精品美女久久久久99小说 | 日韩av无码久久精品免费| 久久精品国产欧美日韩99热| 91精品久久久久久无码| 人人狠狠综合久久亚洲婷婷| 久久久久久久久无码精品亚洲日韩| 一本久道久久综合狠狠躁AV| 久久久不卡国产精品一区二区| 久久精品国产福利国产秒| 国产精品久久久久jk制服| 久久夜色精品国产噜噜亚洲AV| 精品国产乱码久久久久软件| 久久亚洲AV无码精品色午夜| 色综合久久天天综线观看| 亚洲婷婷国产精品电影人久久| 欧美成人免费观看久久| 伊人久久大香线蕉av不卡|