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

            我參與的團隊

            搜索

            •  

            積分與排名

            • 積分 - 388070
            • 排名 - 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 @王一偉 閱讀(1424) 評論(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无码久久精品成人| av午夜福利一片免费看久久| 99久久精品国内| 久久久无码精品亚洲日韩按摩| 国产Av激情久久无码天堂| 久久久黄片| 久久人人爽爽爽人久久久| 国产69精品久久久久99| 久久天天躁狠狠躁夜夜avapp| 久久久女人与动物群交毛片| 精品久久久无码中文字幕天天| 99久久做夜夜爱天天做精品| 91久久精品91久久性色| 欧美亚洲另类久久综合婷婷| 久久永久免费人妻精品下载| 中文字幕精品久久久久人妻| 久久精品麻豆日日躁夜夜躁| 国产精品狼人久久久久影院 | 久久国产精品偷99| 亚洲日本va午夜中文字幕久久 | 亚洲欧美精品伊人久久| 亚洲&#228;v永久无码精品天堂久久| 久久久久久国产精品无码下载| 久久99精品国产99久久6| 无码专区久久综合久中文字幕 | 国内精品伊人久久久久av一坑| 久久香蕉国产线看观看猫咪?v| 97热久久免费频精品99| 久久无码中文字幕东京热| 久久亚洲天堂| 久久av免费天堂小草播放| 青青草国产精品久久久久| 97久久国产亚洲精品超碰热| 人妻精品久久无码专区精东影业 | 久久久久免费看成人影片| 亚洲精品无码久久久久sm| 久久精品综合网| 色综合久久久久久久久五月| 亚洲国产成人久久一区久久 | 久久夜色精品国产噜噜亚洲a| 久久精品?ⅴ无码中文字幕|