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

            我參與的團隊

            搜索

            •  

            積分與排名

            • 積分 - 387045
            • 排名 - 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.
              回復  更多評論
              

            精品无码久久久久久尤物| 久久SE精品一区二区| 99久久国产综合精品网成人影院| 婷婷综合久久狠狠色99h| 久久精品无码专区免费| 大香伊人久久精品一区二区| 久久久久久毛片免费播放| 精品久久人人做人人爽综合| 久久精品国产亚洲AV影院| 色综合久久综精品| 国色天香久久久久久久小说| 久久国产成人午夜AV影院| 久久无码中文字幕东京热| 亚洲国产成人久久综合一 | 精品免费久久久久国产一区| 模特私拍国产精品久久| 青草影院天堂男人久久| 亚洲精品乱码久久久久66| 久久免费国产精品| 国内精品九九久久久精品| 欧美亚洲国产精品久久| 久久99精品久久久久久9蜜桃 | 午夜精品久久影院蜜桃| 精品久久777| 国产成人久久AV免费| 久久人人爽人人爽人人片av麻烦| 国产精品va久久久久久久| 久久精品国产亚洲av影院| 久久精品国产亚洲AV不卡| 久久国产午夜精品一区二区三区| 久久99精品国产麻豆宅宅| 国产成人精品免费久久久久| 波多野结衣中文字幕久久 | 久久精品一区二区三区AV| 亚洲а∨天堂久久精品| 亚洲人AV永久一区二区三区久久 | 久久性精品| 日韩一区二区三区视频久久| 久久久网中文字幕| 久久大香萑太香蕉av| 中文字幕精品无码久久久久久3D日动漫 |