C++:29 --- C++继承关系下的内存布局（下）

1 单继承

C++ 提供继承的目的是在不同的类型之间提取共性。比如，科学家对物种进行分类，从而有种、属、纲等说法。有了这种层次结构，我们才可能将某些具备特定性质的东西归入到最合适的分类层次上，如“怀孩子的是哺乳动物”。由于这些属性可以被子类继承，所以，我们只要知道“鲸鱼、人”是哺乳动物，就可以方便地指出“鲸鱼、人都可以怀孩子”。那些特例，如鸭嘴兽（生蛋的哺乳动物），则要求我们对缺省的属性或行为进行覆盖。 C++中的继承语法很简单，在子类后加上“:base”就可以了。下面的D继承自基类C。

struct C
{
    int c1;
    void cf();
};

struct D : C
{
    int d1;
    void df();
};

既然派生类要保留基类的所有属性和行为，自然地，每个派生类的实例都包含了一份完整的基类实例数据。在D中，并不是说基类C的数据一定要放在D的数据之前，只不过这样放的话，能够保证D中的C对象地址，恰好是D对象地址的第一个字节。这种安排之下，有了派生类D的指针，要获得基类C的指针，就不必要计算偏移量了。几乎所有知名的C++厂商都采用这种内存安排（基类成员在前）。 在单继承类层次下，每一个新的派生类都简单地把自己的成员变量添加到基类的成员变量之后 。 看看上图，C对象指针和D对象指针指向同一地址。

2.多重继承

大多数情况下，其实单继承就足够了。但是，C++为了我们的方便，还提供了多重继承。

比如，我们有一个组织模型，其中有经理类（分任务），工人类（干活）。那么，对于一线经理类，即既要从上级经理那里领取任务干活，又要向下级工人分任务的角色来说，如何在类层次中表达呢？单继承在此就有点力不胜任。我们可以安排经理类先继承工人类，一线经理类再继承经理类，但这种层次结构错误地让经理类继承了工人类的属性和行为。反之亦然。当然，一线经理类也可以仅仅从一个类（经理类或工人类）继承，或者一个都不继承，重新声明一个或两个接口，但这样的实现弊处太多：多态不可能了；未能重用现有的接口；最严重的是，当接口变化时，必须多处维护。最合理的情况似乎是一线经理从两个地方继承属性和行为——经理类、工人类。

C++就允许用多重继承来解决这样的问题：

struct Manager ... { ... };
struct Worker ... { ... };
struct MiddleManager : Manager, Worker { ... };

这样的继承将造成怎样的类布局呢？下面我们还是用“字母类”来举例：

struct E
{
    int e1;
    void ef();
};

struct F : C, E
{
    int f1;
    void ff();
};

结构F从C和E多重继承得来。与单继承相同的是，F实例拷贝了每个基类的所有数据。 与单继承不同的是，在多重继承下，内嵌的两个基类的对象指针不可能全都与派生类对象指针相同：

F f;
// (void*)&f == (void*)(C*)&f;
// (void*)&f < (void*)(E*)&f;

上面那行说明C对象指针与F对象指针相同，下面那行说明E对象指针与F对象指针不同。

观察类布局，可以看到F中内嵌的E对象，其指针与F指针并不相同。正如后文讨论强制转化和成员函数时指出的，这个偏移量会造成少量的调用开销。

具体的编译器实现可以自由地选择内嵌基类和派生类的布局。VC++ 按照基类的声明顺序 先排列基类实例数据，最后才排列派生类数据。 当然，派生类数据本身也是按照声明顺序布局的（本规则并非一成不变 ，我们会看到，当一些基类有虚函数而另一些基类没有时，内存布局并非如此）。

3. 虚继承

回到我们讨论的一线经理类例子。让我们考虑这种情况：如果经理类和工人类都继承自“雇员类”，将会发生什么？

struct Employee { ... };  
struct Manager : Employee { ... };  
struct Worker : Employee { ... };  
struct MiddleManager : Manager, Worker { ... };

如果经理类和工人类都继承自雇员类，很自然地，它们每个类都会从雇员类获得一份数据拷贝。如果不作特殊处理，一线经理类的实例将含有两个雇员类实例，它们分别来自两个雇员基类 。 如果雇员类成员变量不多，问题不严重；如果成员变量众多，则那份多余的拷贝将造成实例生成时的严重开销。更糟的是，这两份不同的雇员实例可能分别被修改，造成数据的不一致。因此，我们需要让经理类和工人类进行特殊的声明，说明它们愿意共享一份雇员基类实例数据。

很不幸，在C++中，这种“共享继承”被称为“虚继承” ，把问题搞得似乎很抽象。虚继承的语法很简单，在指定基类时加上virtual关键字即可。

struct Employee { ... };  
struct Manager : virtual Employee { ... };  
struct Worker : virtual Employee { ... };  
struct MiddleManager : Manager, Worker { ... };

使用虚继承，比起单继承和多重继承有更大的实现开销、调用开销。回忆一下，在单继承和多重继承的情况下，内嵌的基类实例地址比起派生类实例地址来，要么地址相同（单继承，以及多重继承的最靠左基类） ，要么地址相差一个固定偏移量（多重继承的非最靠左基类） 。 然而，当虚继承时，一般说来，派生类地址和其虚基类地址之间的偏移量是不固定的，因为如果这个派生类又被进一步继承的话，最终派生类会把共享的虚基类实例数据放到一个与上一层派生类不同的偏移量处。请看下例：

struct G : virtual C
{
    int g1;
    void gf();
};

GdGvbptrG（In G, the displacement of G’s virtual base pointer to G）意思是：在G中，G对象的指针与G的虚基类表指针之间的偏移量，在此可见为0，因为G对象内存布局第一项就是虚基类表指针；GdGvbptrC（In G, the displacement of G’s virtual base pointer to C）意思是：在G中，C对象的指针与G的虚基类表指针之间的偏移量，在此可见为8。

struct H : virtual C
{
    int h1;
    void hf();
};

struct I : G, H
{
    int i1;
    void _if();
};

暂时不追究vbptr成员变量从何而来。从上面这些图可以直观地看到，在G对象中，内嵌的C基类对象的数据紧跟在G的数据之后，在H对象中，内嵌的C基类对象的数据也紧跟在H的数据之后。但是，在I对象中，内存布局就并非如此了。VC++实现的内存布局中，G对象实例中G对象和C对象之间的偏移，不同于I对象实例中G对象和C对象之间的偏移。当使用指针访问虚基类成员变量时，由于指针可以是指向派生类实例的基类指针，所以，编译器不能根据声明的指针类型计算偏移，而必须找到另一种间接的方法，从派生类指针计算虚基类的位置。 在VC++ 中，对每个继承自虚基类的类实例，将增加一个隐藏的“虚基类表指针”（vbptr） 成员变量，从而达到间接计算虚基类位置的目的。该变量指向一个全类共享的偏移量表，表中项目记录了对于该类 而言，“虚基类表指针”与虚基类之间的偏移量。 其它的实现方式中，有一种是在派生类中使用指针成员变量。这些指针成员变量指向派生类的虚基类，每个虚基类一个指针。这种方式的优点是：获取虚基类地址时，所用代码比较少。然而，编译器优化代码时通常都可以采取措施避免重复计算虚基类地址。况且，这种实现方式还有一个大弊端：从多个虚基类派生时，类实例将占用更多的内存空间；获取虚基类的虚基类的地址时，需要多次使用指针，从而效率较低等等。

在VC++中，G拥有一个隐藏的“虚基类表指针”成员，指向一个虚基类表，该表的第二项是G dGvbptrC。（在G中，虚基类对象C的地址与G的“虚基类表指针”之间的偏移量 （ 当对于所有的派生类来说偏移量不变时，省略“d”前的前缀））。比如，在32位平台上，GdGvptrC是8个字节。同样，在I实例中的G对象实例也有 “虚基类表指针”，不过该指针指向一个适用于“G处于I之中” 的虚基类表，表中一项为IdGvbptrC，值为20。

观察前面的G、H和I， 我们可以得到如下关于VC++虚继承下内存布局的结论： 1 首先排列非虚继承的基类实例； 2 有虚基类时，为每个基类增加一个隐藏的vbptr，除非已经从非虚继承的类那里继承了一个vbptr； 3 排列派生类的新数据成员； 4 在实例最后，排列每个虚基类的一个实例。

该布局安排使得虚基类的位置随着派生类的不同而“浮动不定”，但是，非虚基类因此也就凑在一起，彼此的偏移量固定不变。

4 多重继承下的虚函数

如果从多个有虚函数的基类继承，一个实例就有可能包含多个vfptr。考虑如下的R和S类：

struct R {  
   int r1;  
   virtual void pvf(); // new   
   virtual void rvf(); // new   
};

struct S : P, R {  
   int s1;  
   void pvf(); // overrides P::pvf and R::pvf   
   void rvf(); // overrides R::rvf   
   void svf(); // new   
};

这里R是另一个包含虚函数的类。因为S从P和R多重继承，S的实例内嵌P和R的实例，以及S自身的数据成员S::s1。注意，在多重继承下，靠右的基类R，其实例的地址和P与S不同。S::pvf覆盖了P::pvf()和R::pvf()，S::rvf()覆盖了R::rvf()。

S s; S* ps = &s;  
((P*)ps)->pvf(); // (*(P*)ps)->P::vfptr[0])((S*)(P*)ps)   
((R*)ps)->pvf(); // (*(R*)ps)->R::vfptr[0])((S*)(R*)ps)   
ps->pvf();       // one of the above; calls S::pvf()

调用((P*)ps)->pvf()时，先到P的虚函数表中取出第一项，然后把ps转化为S*作为this指针传递进去； 调用((R*)ps)->pvf()时，先到R的虚函数表中取出第一项，然后把ps转化为S*作为this指针传递进去；

因为S::pvf()覆盖了P::pvf()和R::pvf()，在S的虚函数表中，相应的项也应该被覆盖。然而，我们很快注意到，不光可以用P*，还可以用R*来调用pvf()。问题出现了：R的地址与P和S的地址不同。表达式(R*)ps与表达式(P*)ps指向类布局中不同的位置。因为函数S::pvf希望获得一个S*作为隐藏的this指针参数，虚函数必须把R*转化为S*。因此，在S对R虚函数表的拷贝中，pvf函数对应的项，指向的是一个“调整块 ”的地址，该调整块使用必要的计算，把R*转换为需要的S*。 这就是“thunk1: this-= sdPR; goto S::pvf”干的事。先根据P和R在S中的偏移，调整this为P*，也就是S*，然后跳转到相应的虚函数处执行。

在微软VC++实现中，对于有虚函数的多重继承，只有当派生类虚函数覆盖了多个基类的虚函数时，才使用调整块。

5 地址点与“逻辑this调整”

考虑下一个虚函数S::rvf()，该函数覆盖了R::rvf()。我们都知道S::rvf()必须有一个隐藏的S*类型的this参数。但是，因为也可以用R*来调用rvf()，也就是说，R的rvf虚函数槽可能以如下方式被用到：

1. ((R*)ps)->rvf(); // (*((R*)ps)->R::vfptr[1])((R*)ps)
2. ((R*)ps)->rvf(); // (*((R*)ps)->R::vfptr[1])((R*)ps)

所以，大多数实现用另一个调整块将传递给rvf的R*转换为S*。还有一些实现在S的虚函数表末尾添加一个特别的虚函数项，该虚函数项提供方法，从而可以直接调用ps->rvf()，而不用先转换R*。MSC++的实现不是这样，MSC++有意将S::rvf编译为接受一个指向S中嵌套的R实例，而非指向S实例的指针（我们称这种行为是“给派生类的指针类型与该虚函数第一次被引入时接受的指针类型相同”）。所有这些在后台透明发生，对成员变量的存取，成员函数的this指针，都进行“逻辑this调整”。

当然，在debugger中，必须对这种this调整进行补偿。

ps->rvf(); // ((R*)ps)->rvf(); // S::rvf((R*)ps)

调用rvf虚函数时，直接给入R*作为this指针。

所以，当覆盖非最左边的基类的虚函数时，MSC++一般不创建调整块，也不增加额外的虚函数项。

6 调整块

正如已经描述的，有时需要调整块来调整this指针的值（this指针通常位于栈上返回地址之下，或者在寄存器中），在this指针上加或减去一个常量偏移，再调用虚函数。某些实现（尤其是基于cfront的）并不使用调整块机制。它们在每个虚函数表项中增加额外的偏移数据。每当虚函数被调用时，该偏移数据（通常为0）,被加到对象的地址上，然后对象的地址再作为this指针传入。

ps->rvf();  
// struct { void (*pfn)(void*); size_t disp; };   
// (*ps->vfptr[i].pfn)(ps + ps->vfptr[i].disp);

当调用rvf虚函数时，前一句表示虚函数表每一项是一个结构，结构中包含偏移量；后一句表示调用第i个虚函数时，this指针使用保存在虚函数表中第i项的偏移量来进行调整。

这种方法的缺点是虚函数表增大了，虚函数的调用也更加复杂。

现代基于PC的实现一般采用“调整—跳转”技术：

S::pvf-adjust: // MSC++   
this -= SdPR;  
goto S::pvf();

当然，下面的代码序列更好（然而，当前没有任何实现采用该方法）：

S::pvf-adjust:  
this -= SdPR; // fall into S::pvf()   
S::pvf() { ... }

IBM的C++编译器使用该方法。

7 虚继承下的虚函数

T虚继承P，覆盖P的虚成员函数，声明了新的虚函数。如果采用在基类虚函数表末尾添加新项的方式，则访问虚函数总要求访问虚基类。在VC++中，为了避免获取虚函数表时，转换到虚基类P的高昂代价，T中的新虚函数通过一个新的虚函数表 获取 ，从而带来了一个新的虚函数表指针。该指针放在T实例的顶端。

struct T : virtual P {  
   int t1;  
   void pvf();         // overrides P::pvf   
   virtual void tvf(); // new   
};  
void T::pvf() {  
   ++p1; // ((P*)this)->p1++; // vbtable lookup!   
   ++t1; // this->t1++;   
}

如上所示，即使是在虚函数中，访问虚基类的成员变量也要通过获取虚基类表的偏移，实行计算来进行。这样做之所以必要，是因为虚函数可能被进一步继承的类所覆盖，而进一步继承的类的布局中，虚基类的位置变化了。 下面就是这样的一个类：

struct U : T {  
   int u1;  
};

在此U增加了一个成员变量，从而改变了P的偏移。因为VC++实现中，T::pvf()接受的是嵌套在T中的P的指针，所以，需要提供一个调整块，把this指针调整到T::t1之后（该处即是P在T中的位置）。

8 虚析构函数与delete操作符

假如A是B的父类， A* p = new B(); 如果析构函数不是虚拟的，那么，你后面就必须这样才能安全的删除这个指针： delete (B*)p; 但如果构造函数是虚拟的，就可以在运行时动态绑定到B类的析构函数，直接： delete p; 就可以了。这就是虚析构函数的作用。 实际上，很多人这样总结：当且仅当类里包含至少一个虚函数的时候才去声明虚析构函数。 考虑结构V和W。

struct V {  
   virtual ~V();  
};  
struct W : V {  
   operator delete();  
};

析构函数可以为虚。一个类如果有虚析构函数的话，将会象有其他虚函数一样，拥有一个虚函数表指针，虚函数表中包含一项，其内容为指向对该类适用的虚析构函数的地址。这些机制和普通虚函数相同。虚析构函数的特别之处在于：当类实例被销毁时，虚析构函数被隐含地调用。调用地（delete发生的地方）虽然不知道销毁的动态类型，然而，要保证调用对该类型合适的delete操作符。例如，当pv指向W的实例时，当W::~W被调用之后，W实例将由W类的delete操作符来销毁。

V* pv = new V;  
delete pv;   // pv->~V::V(); // use ::operator delete()   
pv = new W;  
delete pv;   // pv->~W::W(); // use W::operator delete() 动态绑定到 W的析构函数，W默认的析构函数调用{delete this;}   
pv = new W;  
::delete pv; // pv->~W::W(); // use ::operator delete()

V没有定义delete操作符，delete时使用函数库的delete操作符； W定义了delete操作符，delete时使用自己的delete操作符； 可以用全局范围标示符显示地调用函数库的delete操作符。 为了实现上述语意，VC++扩展了其“分层析构模型”，从而自动创建另一个隐藏的析构帮助函数——“deleting析构函数”，然后，用该函数的地址来替换虚函数表中“实际”虚析构函数的地址。析构帮助函数调用对该类合适的析构函数，然后为该类有选择性地调用合适的delete操作符。