• <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.
              回復  更多評論
              

            国产成人久久久精品二区三区 | 久久涩综合| 欧美熟妇另类久久久久久不卡| 亚洲а∨天堂久久精品9966| 91久久福利国产成人精品| 99国产精品久久久久久久成人热| 久久久久久毛片免费播放| 亚洲精品乱码久久久久久蜜桃图片 | 欧美激情精品久久久久久久| 久久精品无码一区二区三区日韩| 99久久夜色精品国产网站| 99久久99久久精品免费看蜜桃| 国产精品久久久久久久久鸭 | 中文字幕日本人妻久久久免费 | 亚洲国产成人精品女人久久久 | 久久99精品国产自在现线小黄鸭| 亚洲中文久久精品无码ww16| 久久久久99精品成人片直播| 久久精品国产亚洲AV麻豆网站| 97超级碰碰碰久久久久| 99久久99久久精品国产片果冻| 久久国产精品偷99| 久久影视综合亚洲| 色欲综合久久中文字幕网| 久久国产亚洲精品无码| 91精品国产91久久久久久蜜臀| 久久国产精品无码网站| 午夜欧美精品久久久久久久| 精品免费tv久久久久久久| 精品久久久久中文字| 久久人人爽人人人人片av| 国产精品99久久99久久久| 久久精品国产亚洲Aⅴ香蕉| 一级做a爰片久久毛片免费陪 | 国产精品美女久久久免费| 久久精品卫校国产小美女| 亚洲国产成人久久精品动漫| 久久久久久免费视频| 亚洲国产成人久久精品影视| 精品人妻伦九区久久AAA片69| 人人狠狠综合久久亚洲婷婷|