CSDN博客

img Viper

[深度探索C++对象模型](简体版)中的蛇足

发表于2001/10/10 13:24:00  3378人阅读

分类: 以前的文章

 

<深度探索C++对象模型>>(简体版)中的蛇足

(没有此书的人请勿看)

上次见到这本书是一年前(是候先生的繁体版),花了一个星期的时间读完,囫囵吞枣,不求甚解,饶是如此,也解决了我在C++方面的诸多疑惑,这次终于看到了简体版,同样花了一个星期,或许真的是一回生,两回熟吧(也可能是对简体文字的亲切感^_^),思考问题的同时也发现了一些问题,一愚之见,不吐不快。

蛇足之一,P84,

class X {};

class Y : public virtual X {};

class Z : public virtual Z {};

class A : public X, pubic Z {};

书中写到

事实上这个大小受到3个因素的影响,

1)      语言本身所造成的额外负担,。

2)      编译器对于特殊情况所提拱的优化处理。。

3)      Alignment的限制。。

候先生自己添加的示意图如下:

 

当时看这个图真是“百思不得其解”,无论对于Y或Z来说,既然已经从X virtual继承,也就有了的额外的4byte开销,也就是说已经不是一个empty class,那个1 char byte for Y(Z) is empty也就说不通了,而且从lippman的本意来看,

              “2)编译器对于特殊情况所提供的优化处理,virtual base class X的1byte subobject也出现在class Y和Z身上,传统上它被放在derived class的固定(不变动)部分的尾端”,P88中说明,“它把数据直接存放于每一个class object之中,对于继承而来的nonstatic data member(不管是virtual或nonvirtual base class)均是如此”,

因此,我理解的图应该是这样的:

 

也就是说,父类中成员是直接继承到子类中的,只不过对于虚拟继承来说,需要通过一个间接层(表现为某种形式的指针)来存取,这一想法在3.5节(虚拟继承)中再次得到验证,(见P121),书中还提到,empty base class的优化通常把empty base class置于derived class object开头一部分,从而不花费任何额外空间。由此也可以分析出,A的结构如下:(本书中,候先生没有给出这张图)

sizeof(A)为12个byte,在empty base class优化的情况下,为8个Byte。

蛇足之二,P234,

候先生改动了lippman的顺序(指析构时发生的事情),他的根据是“这样才符合ctor的相反顺序”,这也未免太主观了一点,过于咬文嚼字了吧,君不见lippman说“2,dtor的函数本身现在被执行,也就是说vptr会在程序员的码执行之前被重设”,事实上。

struct b {};

struct d1 : virtual public b {};

struct d2 : virtual public b {};

struct d : public d1, d2 {};


Ctor如下: (可参考Vertex3d的ctor)

d()
{
if( __most_derived )
    this->b();

this->d1(false), this->d2(false);

vptr = d::vptr;
// usercode
}

file://编译器扩充dtor如下,按相反顺序。
~d()
{
vptr = d::vptr;    //**//
//user code...

this->~d2(false), this~d1(false);
if( __most_derived )
    this->~b();

}

这不就是lippman的意思吗(见书上从1到5的顺序)?候先生所谓的相反自定义的顺序反而难以理解。

当d被析构的时候,先设vptr = d::vptr,再执行析构函数体,然后依次设d2::vptr, d1::vptr, 最后b::vptr,这些都很容易明白。

而候先生第3点表明“如果object内带一个vptr,则现在被重新设定,指向适当之base class的virtual table”,即认为vptr的设定为跳跃式的,是在~d()中user code 执行完之后(//**//标记的那行不执行),设定vptr 为d2::vptr,然后执行~d2()函数体,最后在~d2()的末尾设定vptr为d1::vptr,再执行~d1(),奇哉!

这可是一个类设定vptr为另一个不相关的类的vptr啊,它们之间可是没有母子关系的噢。个人觉得候先生所制定的顺序过于理论化了,而lippman的方法是从实际出发的。

蛇足之三:P263

class Point

{

public:

       virtual ~Point() {}

};

 

class Point3d : public Point

{

};

 

Point *ptr = new Point3d[10];

for( int ix = 0 ; ix < elem_count ; ++ix )

{

       Point *p = &((Point3d*)ptr)[ix];

       delete p;

}

候先生将之改为:

for( int ix = 0 ; ix < elem_count ; ++ix )

{

       Point3d *p = &((Point3d*)ptr)[ix];

       delete p;

}

这一处很明显,虚拟析构函数用不着指定明显类型,就算指定了类型,都是被resolve成(p->vptr[1])(p),不会带来性能上的改善。

最后指出一点,lippman认为

Point *ptr = new Point3d[10];

delete[] ptr;

“这样做完全不是个好主意(具体解释见P263)”,或许在他那个时候不是吧^_^,但就我在VC6上的测试结果,是完全正确的,所以大家还是可以放心的这样用,(我没有测试其它编译器,有兴趣的可以自己试试)。

佳节之日,仓促成文,恐词不答意,请见谅。
                                                                    19时16分2001/10/1

0 0

相关博文

我的热门文章

img
取 消
img