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

            醬壇子

            專注C++技術 在這里寫下自己的學習心得 感悟 和大家討論 共同進步(歡迎批評!!!)

              C++博客 :: 首頁 :: 聯系 :: 聚合  :: 管理
              66 Posts :: 16 Stories :: 236 Comments :: 0 Trackbacks

            公告

            王一偉 湖南商學院畢業 電子信息工程專業

            常用鏈接

            留言簿(19)

            我參與的團隊

            搜索

            •  

            積分與排名

            • 積分 - 387109
            • 排名 - 64

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

            inheritance的重要性質就是你可以通過指向base class objects的pointers或者references來操作derived class object.

            同樣C++也允許你使用pointers或者references來操作derived class object形成的數組。但是這樣的行為很危險,幾乎不會按你設定的方式運作。

            我們來舉個例子:

            ?class?A{};
            ?class?B:public?A{};

            ?//現在我們有一個函數
            void?printAArray(ostream&?s,const?A?array[],int?numElement)
            {
            ???
            ??? for(int?i=0;i<numElement;++i)
            ??????
            {
            ??????????? s
            <<array[i];//假設A?objects中有一個operator<<可以用?
            ?
            ???? }

            }


            當你把A AArray[10];傳給他
            ...
            printAArray(cout,AArray,10);//運作良好

            但是當你把B BArray傳給他
            printAArray(cout,BArray,10);//還能正常運作嗎

            毫無疑問,編譯時編譯器會很開心的接受他。但是運行時呢
            ?for(int?i=0;i<numElement;++i)
            ??
            {
            ??????????? s
            <<array[i];//假設A?objects中有一個operator<<可以用?
            ?
            }
            就會出問題,array所指向的內存和array+i所指向的內存有多遠的距離
            答案是i*sizeof(A),但是我們在穿BArray的時候我們需要的是i*sizeof(B),因為
            derived class object通常比base class object 大。

            同樣你通過bass class來刪除derived class object的時候,都會產生不可預期的錯誤

            簡單的說,大家需要注意的一點就是,數組不要和多態進行混合使用,因為數組總是會涉及指針
            的算術運算。

            當然這個也不是絕對的,都是內存訪問惹的禍

            如果你能夠避免一個具象類(帶有參數的類)繼承自另外的一個具象類,你就不太能犯
            下這樣的錯誤。

            具體的內容我晚上在下一篇隨筆里面進行介紹
            posted on 2007-01-31 09:44 @王一偉 閱讀(1417) 評論(7)  編輯 收藏 引用

            Feedback

            # re: 不要使用polymorphically方式處理數組 2007-01-31 23:23 Elvis
            個人覺得這是一個典型的對象切片~A AArray[10]中的10個A對象的實例是分配在棧上的靜態對象,而不是分配在堆上的動態對象吧~這樣的話其實就不存在多態了,因為多態是對指針對象而言的,于是當將子類對象賦給基類對象時,對象切片就發生了~  回復  更多評論
              

            # re: 不要使用polymorphically方式處理數組 2007-02-01 11:23 王一偉
            不是吧,棧內我還是可以調用函數的,再入棧一次就是了,我仍然可以使用指針方式進行參數傳遞。
            確實,這個是一個切片現象。
            呵呵
            老兄 發覺這人好少啊 我想搬去csdn了 那人好多  回復  更多評論
              

            # re: 不要使用polymorphically方式處理數組 2007-02-02 01:08 OOMusou
            Elvis說的沒錯
            很典型的Object Slicing
            請看Effective C++ 條款20  回復  更多評論
              

            # re: 不要使用polymorphically方式處理數組 2007-02-02 09:15 holyfire
            這根本不是多態的運用方式,C++下使用多態要用基類指針的方式,看來你還需要加強下基礎  回復  更多評論
              

            # re: 不要使用polymorphically方式處理數組 2007-02-02 11:41 王一偉
            恩,我馬上去瞧瞧Effective C++ 條款20,汗 我還沒看到那

            但是這個不是多態需要的基類指針的方式我就表示懷疑了,
            只要virtual了base class的destructor 感覺后面的問題就可以解決了

            多謝大家關心,不過還是希望大家能詳細點告訴我錯在哪里 嘿嘿 基礎差偶歡迎大家批評 呵呵 最近惡補基礎


              回復  更多評論
              

            # re: 不要使用polymorphically方式處理數組 2007-02-03 01:52 Elvis
            PS:你說的這個問題在C++ CODING STANDARDS的第100條有論述~  回復  更多評論
              

            # re: 不要使用polymorphically方式處理數組 2007-02-03 09:03 醬菜
            呵呵 是的 Elvis兄

            Don't treat arrays polymorphically

            Pointers serve two purposes at the same time: that of monikers (small identifiers of objects), and that of array iterators (they can walk through arrays of objects using pointer arithmetic). As monikers, it makes a lot of sense to treat a pointer to Derived as a pointer to Base. As soon as the array iteration part enters the stage, however, such substitutability breaks down because an array of Derived isn't the same as an array of Base. To illustrate: Mice and elephants are both mammals, but that doesn't mean a convoy of a thousand elephants would be as long as one of a thousand mice.

            Size does matter. When substituting a pointer to Derived to a pointer to Base, the compiler knows exactly how to adjust the pointer (if necessary) because it has enough information about both classes. However, when doing pointer arithmetic on a pointer p to Base, the compiler computes p[n] as *(p + n * sizeof(Base)), thus assuming that the objects lying in memory are all Base objectsand not objects of some derived type that might have a different size. Imagine, now, just how easy it is to tromp all over of an array of Derived if you convert the pointer marking its start to Base* (with compiler's silent approval) and then perform pointer arithmetic on that pointer (while the compiler doesn't blink an eye either)!

            Such accidents are an unfortunate interaction between substitutability, which dictates that pointers to derived classes should be usable as pointers to their bases, and C's legacy pointer arithmetic, which assumes pointers are monomorphic and uses solely static information to compute strides.

            To store arrays of polymorphic objects, you need an array (or, better still, a real container; see Item 77) of pointers to the base class (e.g., plain pointers or, better still, shared_ptrs; see Item 79). Then each pointer in the array refers to a polymorphic object, likely an object allocated on the free store. Or, if you want to expose an interface to a container of polymorphic objects, you need to encapsulate the entire array and offer a polymorphic interface for iteration.

            Incidentally, a good reason to prefer references to pointers in interfaces is to make it clear that you're talking about one object, as opposed to possibly an array of them.
              回復  更多評論
              

            久久久久亚洲AV无码专区网站 | Xx性欧美肥妇精品久久久久久 | 无码乱码观看精品久久| 久久中文字幕人妻丝袜| 成人久久综合网| 久久久高清免费视频| 欧美大香线蕉线伊人久久| 性高朝久久久久久久久久| 99国产欧美精品久久久蜜芽| 国产亚州精品女人久久久久久 | 国产成人久久精品二区三区| 伊人 久久 精品| 久久国产高清字幕中文| 狠狠色丁香久久婷婷综合蜜芽五月 | A级毛片无码久久精品免费| 天天久久狠狠色综合| 亚洲综合精品香蕉久久网| 久久本道综合久久伊人| 国产精品久久波多野结衣| 亚洲中文精品久久久久久不卡| 久久av免费天堂小草播放| 久久久久久久综合日本亚洲 | 伊人久久五月天| 久久99精品久久久久久齐齐| 精品国际久久久久999波多野| 91麻豆国产精品91久久久| 香蕉99久久国产综合精品宅男自 | 久久无码人妻精品一区二区三区 | 亚洲精品无码久久不卡| 国产精自产拍久久久久久蜜 | 欧美亚洲国产精品久久| 中文精品久久久久人妻| 人妻少妇精品久久| 久久中文精品无码中文字幕| 久久AAAA片一区二区| 欧美日韩精品久久久免费观看| 国产成人无码精品久久久久免费 | 99久久国语露脸精品国产| 久久亚洲AV成人无码电影| 欧洲人妻丰满av无码久久不卡| 无码国内精品久久人妻|