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

 

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