醬壇子

個(gè)人覺得這是一個(gè)典型的對象切片～A AArray[10]中的10個(gè)A對象的實(shí)例是分配在棧上的靜態(tài)對象，而不是分配在堆上的動(dòng)態(tài)對象吧～這樣的話其實(shí)就不存在多態(tài)了，因?yàn)槎鄳B(tài)是對指針對象而言的，于是當(dāng)將子類對象賦給基類對象時(shí)，對象切片就發(fā)生了～  回復(fù)  更多評論
  

不是吧，棧內(nèi)我還是可以調(diào)用函數(shù)的，再入棧一次就是了，我仍然可以使用指針方式進(jìn)行參數(shù)傳遞。
確實(shí)，這個(gè)是一個(gè)切片現(xiàn)象。
呵呵
老兄 發(fā)覺這人好少啊 我想搬去csdn了 那人好多  回復(fù)  更多評論
  

Elvis說的沒錯(cuò)
很典型的Object Slicing
請看Effective C++ 條款20  回復(fù)  更多評論
  

這根本不是多態(tài)的運(yùn)用方式,C++下使用多態(tài)要用基類指針的方式,看來你還需要加強(qiáng)下基礎(chǔ)  回復(fù)  更多評論
  

恩，我馬上去瞧瞧Effective C++ 條款20，汗 我還沒看到那

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

多謝大家關(guān)心，不過還是希望大家能詳細(xì)點(diǎn)告訴我錯(cuò)在哪里 嘿嘿 基礎(chǔ)差偶?xì)g迎大家批評 呵呵 最近惡補(bǔ)基礎(chǔ)


  回復(fù)  更多評論
  

PS：你說的這個(gè)問題在C++ CODING STANDARDS的第100條有論述~  回復(fù)  更多評論
  

呵呵 是的 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.
  回復(fù)  更多評論