<深度探索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