C++对象内存模型

C++对象内存模型

C语言中数据和处理数据的函数是分别定义，各个处理数据的函数实现相应各种算法。但是C++提供了类，可以实现较好的数据和处理数据的算法的封装性，这种封装性相比较C语言而言会带来一些成本，这主要受制于是C++对象为支持相应特性而实现的内存模型。

C++程序内部格局通常分为四个区：

• 全局数据区：静态数据和常量
• 代码区：所以类成员函数和非成员函数代码
• 栈区：就是那些由编译器在需要的时候分配，在不需要的时候自动清除的变量的存储区。里面的变量通常是局部变量、函数参数等。
• 堆区：程序中，由程序员申请的内存空间（new、malloc）。空间的释放一般也有程序员控制（一个new对应一个delete）。当程序员没有释放该内存空间的时候，程序运行完毕时操作系统会对该内存空间进行回收。

C++中分别有static和nonstatic两种数据成员，有static、nonstatic、virtual三种成员函数。对于一个类的对象的内存布局方式主要经过一下演变。

static数据成员属于类,该类的所有对象共享static数据成员，static数据成员存储在 静态存储区。
对象数据成员依据创建对象的方式不同，可能存在于栈上或者堆上。
成员函数存储在代码段。

当对象被创建，编译器会为每个对象分配内存空间，包括成员变量以及成员函数。

• 类的大小与数据成员有关与成员函数无关
• 类的大小与静态数据成员无关
• 虚继承对类的大小的影响
• 虚函数对类的大小的影响

可以直观的认识，如果定义了10个对象，那么就要分别为这10个对象的变量和函数分配内存空间，

对象1	对象2	...	对象10
成员变量	成员变量	...	成员变量
成员函数	成员函数	...	成员函数

虽然每个对象的成员变量不同，但是成员函数的运行代码确是一样的，上么内存模型保存了10份相同的代码片段，浪费内存空间,调用不同对象的成员函数时都是执行同一段函数代码，但是执行结果一般是不相同的。不同的对象使用的是同一个函数代码段，它怎么能够分别对不同对象中的数据进行操作呢？原来C++为此专门设立了一个名为this的指针，用来指向不同的对象。

在实际上，编译器会将成员变量和成员函数分开存储：分别为每个对象饿成员变量分配内存，但是所有对象都共享同一段函数代码。

对象1	对象2	...	对象3
成员变量	成员变量	...	成员变量
公有成员函数

一、内存布局方式

（一）简单的对象模型

每个对象是一系列的内存，每个内存保存的都是一个指针，指向成员（所以成员函数、数据成员）。所有数据按照声明方式进行排列。

简单模型中，可以避免不同成员类型需要不同存储空间带来的问题，同时一个对象的大小很容易计算出来。这种最简单的模型在成员指针的实现中有深入的应用。

（二）表格内存模型

将数据成员全部放在一个表格中，包含数据成员的实际存储；成员函数放在另一个表格中，每一项为一个函数指针指向相应的成员函数。对于每个对象的内存布局中，只包含两个指针分别指向这两个表格。

二、C++对象内存布局

通过两种基本模型演变和发展，可以得知C++对象内存布局：

• 对象包含所以non-static数据成员，static数据成员和所有函数成员都不放在对象内。
• static数据成员放置在全局数据区
• non-virtual函数成员（static和non-static）与普通non-member函数相同，
• static直接调用
• non-static需要使用对象的this指针调用
• virtual函数成员通过虚函数表格（virtual function table,vtbl）与虚函数表指针（virtual function pointer, vptr）来实现，bptr一般放置在对象的首地址起始处。

虚函数表指针（vptr）只有在类存在虚函数时才会由编译器添加，此时也会由编译器进行constructor、destructor和copy assignmeh运算符函数的设置。同时，存在虚函数的类生成的虚函数表，都会在第一项设置与该类相关联的type info信息，用来完成C++的RTTI特性。

内存布局主要优点是空间利用率和存取时间的效率都较优。主要缺点就是，如果应用程序代码不曾改变，但是object的non-static数据成员有修改，那么由于object直接存储了这些数据成员，因此必须重新编译。

一个C++对象的内存布局大小主要由几个因素决定：

1.类中定义的nonstatic数据成员的总和

2.由于alignment需求编译器进行的padding

3.为了支持virtual特性添加的额外负担(vptr和vcptr)

C++对象为了支持多态特性，只能引用或指针来完成，实际对象进行调用时无法完成多态。有三种实现方式：

1.继承类指针隐式转换为基类指针

2.基类指针调用虚函数

3.dynamic_cast和typeid运算符完成

1.C结构（struct）

由于C++是基于C，所以C++也“基本上”能够兼容C。特别地，C++规范在“结构”上使用了和C相同的，简单的内存布局原则：成员变量按其被声明的顺序排序，按具体实现所规定的对齐原则在内存地址上对齐。所有的C/C++厂商都保证他们的C/C++编译器对于有效的C结构采用完全相同的布局。A是一个简单C结构，其成员布局和对齐方式一目了然。

struct A{
    char c;
    int i;
};

注：A在内存中占有8个字节，按声明成员顺序，前4个字节包含一个字符（实际占用1个字节，3个字节空着，补对齐），后4个字节包含一个整数。A的指针就指向字符开始字节处。

2.有C++特征的C结构

C++不是复杂的C，C++本质上是面向对象的语言：包含继承，封装以及多态。原始C结构可以经过改造。改成面向对象——类。除了成员变量外，C++类还可以封装成员函数和其他东西。然而，除非为了实现虚函数和虚继承引入隐藏成员变量外，C++类实例的大小完全取决于一个类及其基类的成员变量。成员函数基本上不影响类实例的大小。

控制成员可见性的：“public/protected/private”关键字、成员函数、静态成员、嵌套的类型声明；实际上，只有成员变量才占有类实例的空间。注意：C++标准不会限制“public/protecter/private”关键字分开的各段在实现时候的先后顺序。所以不同编译器实现的内存布局可能不同。

struct B{
    public:
        int bm1;
    protected:
        int bm2;
    private:
        int bm3;
        static int bsm;
        void bf();
        static void bsf();
        typedef void *bpv;
        struct N{};
};

注：static int bsm不占用内存空间，因为静态成员，数据会存放在程序的数据段，不会在实例中。

3.1单继承

C++提供继承的目的是在不同的类型之间提取不同类型的共性。在子类后加上"继承方式(public/protected/private):base",

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

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

派生类要保留基类的所有属性和行为，自然地，每个派生类的实力都包含了一份完整的基类实例数据。在D中，并不是说基类C的数据一定要放在D的数据之前。这样放的话，能够保证D中的C对象地址，恰好是D对象地址的第一个字节。这种安排下，有了派生类D的指针，要获取基类C的指针，就不必计算偏移量。在单继承类层次下，每一个新的派生类都简单地把自己成员变量添加到基类的成员变量后。

3.2多重继承

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

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

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

这样继承将造成怎样类布局

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

struct F:C,E{
    void 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指针并不相同。在强制转换和成员函数会造成少量的调用开销。

编译器实现可以自由地选择内嵌基类和派生类的布局。

3.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 q1;
    void fC();
};

注：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();  
};  

在G对象中，内嵌的C基类对象的数据紧跟在G的数据之后，在H对象中，内嵌的C基类对象的数据也紧跟在H的数据之后。但是， 在I对象中，内存布局就并非如此了。VC++实现的内存布局中，G对象实例中G对象和C对象之间的偏移，不同于I对象实例中G对象和C对象之间的偏移。当 使用指针访问虚基类成员变量时，由于指针可以是指向派生类实例的基类指针，所以，编译器不能根据声明的指针类型计算偏移，而必须找到另一种间接的方法，从 派生类指针计算虚基类的位置。 

对每个继承自虚基类的类实例，将增加一个隐藏的“虚基类表指针”（vbptr） 成员变量，从而达到间接计算虚基类位置的目的。该变量指向一个全类共享的偏移量表，表中项目记录了对于该类 而言，“虚基类表指针”与虚基类之间的偏移量。 

有一种是在派生类中使用指针成员变量。这些指针成员变量指向派生类的虚基类，每个虚基类一个指针。这种方式的优点是：获取虚基类地址时， 所用代码比较少。然而，编译器优化代码时通常都可以采取措施避免重复计算虚基类地址。况且，这种实现方式还有一个大弊端：从多个虚基类派生时，类实例将占 用更多的内存空间；获取虚基类的虚基类的地址时，需要多次使用指针，从而效率较低等等。

G拥有一个隐藏的“虚基类表指针”成员，指向一个虚基类表，在G中，虚基类对象C的地址与G的“虚基类表指针”之间的偏移量（当对于所有的派生类来说偏移量不变时，省略“d”前的前缀）。

通过观察前面G、H和I的内存分布，可以得知虚继承下内存布局结论：

1.首先排列非虚继承的基类实例；

2.有虚基类时，为每个基类增加一个隐藏的vbptr，除非已经从非虚继承的类来继承一个vbptr；

3.排列派生类的新数据成员；

4.在实例最后，排列每个虚基类的一个实例。

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

4.成员变量

不同继承方式，访问成员变量的开销。

没有继承：在没有任何继承关系时，访问成员变量与C语言情况完全一样：从指向对象的指针，考虑一定的偏移量。

C* pc;
pc->c1;  //*(pc+dCc1);

注：pc是指向C的指针。

a.访问C的成员变量c1，只需要在pc上加上固定的偏移量dCc1

单继承：由于派生类实例与其基类实例之间的偏移量是常数0，所以可以直接利用基类的指针和基类成员之间的偏移量关系。

D* pd;
pd->c1;  //*(pd+dDC+dCc1); //*(pd+dDc1);
pd->d1;  //*(pd+dDd1);

注：D从C单继承，pd为指向D的指针。

1.当访问基类成员c1时，计算步骤本来应该为"pd+dDC+dCc1"，先计算D对象和C对象之间的偏移，再在此基础上加上C对象指针与成员变量c1之间的偏移量。然而，由于dDC恒定为0，所以直接计算C对象地址与c1之间的偏移就行。

2.当访问派生类成员d1时，直接计算偏移量。

多重继承：派生类与某个基类之间的偏移量可能不为0，然而，该偏移量总是一个常数。只要是个常数，访问成员变量，计算成员变量偏移时就可以简化。所以就算是多重继承，访问成员变量开销仍然不大。

F* pf;
pf->c1;    //*(pf+dFC+dCc1); //*(pf+dFc1);
pf->e1;        //*(pf+dFE+dEe1);   //*(pf+dFe1);
pf->f1;    //*(pf+dFf1);

注：F继承自C和E，pf是指向F对象的指针。

访问C类成员c1时，F对象与内嵌C对象的相对偏移为0，

访问E类成员e1时，F对象与内嵌E独享的相对偏移量是一个常数，F和e1之间的偏移量也可以简化

访问F自己的成员f1时，直接计算偏移量。

虚继承：当类有虚基类时，访问非虚基类的成员仍然是计算固定偏移量的问题。然而，访问虚基类的成员变量，开销将会增大。需要经过3步才能得到成员变量的指针。

1.获取“虚基类表指针”

2.获取虚基类表中某一表项的内容；

3.把内容中指定偏移量加到“虚基类表指针”的地址上。

如果不是通过指针访问，而是直接通过对象实例，而是派生类的布局可以在编译期间静态获得，偏移量也可以在编译时计算，因此也就不必要根据虚基类表的表项来间接计算了。

l* pi;      
pi->c1;   // *(pi + dIGvbptr + (*(pi+dIGvbptr))[1] + dCc1);
pi->g2;   //*(pi + dIG + dGg1); // *(pi + dIg1);  
pi->h1;  //*(pi + dIH + dHh1); // *(pi + dIh1);  
pi->i1;  //*(pi + dIi1);   
l i;
i.c1;  //*(&i + IdIC + dCc1); // *(&i + IdIc1);   

注：I继承自G和H，G和H的虚基类是C，pi是指向I对象的指针。

1.访问虚基类C的成员c1时，dlGvbptr是“在l中，l对象指针与G的”“虚基类表指针”之间的偏移”，*(pi + dIGvbptr)是虚基类表的开始地址，*(pi + dIGvbptr)[1]是虚基类表的第二项的内容（在I对象中，G对象的“虚基类表指针”与虚基类之间的偏移），dCc1是C对象指针与成员变量c1之 间的偏移；

2.访问非虚基类G的成员g1时，直接计算偏移量；

3.访问非虚基类H的成员h1时，直接计算偏移量；

4.访问自身成员i1时，直接使用偏移量；

5.当声明了一个对象实例，用点“.”操作符访问虚基类成员c1时，由于编译时就完全知道对象的布局情况，所以可以直接计算偏移量。

当访问类继承层次中，多层虚基类的成员变量时，情况又如何呢？比如，访问虚基类 的虚基类的成员变量时？一些实现方式为：保存一个指向直接虚基类的指针，然后就可以从直接虚基类找到它的虚基类，逐级上推。VC++优化了这个过程。 VC++在虚基类表中增加了一些额外的项，这些项保存了从派生类到其各层虚基类的偏移量。

5 强制转换

假如没有虚基类的问题，将一个指针强制转化为另一个类型的指针代价并不高昂。如果在要求转化的两个指针之间有“基类-派生类”关系，编译器只需要简单地在两者之间加上或者减去一个偏移量即可（并且该量还往往为0）。

F* pf;
(C*)pf; // (C*)(pf ? pf + dFC : 0); // (C*)pf; 
(E*)pf;  // (E*)(pf ? pf + dFE : 0); 

C和E是F的基类，将F的指针pf转化为C*或E*，只需要将pf加上一个相应的偏移量。转化为C类型指针C*时，不需要计算，因为F和C之间的偏移量为 0。转化为E类型指针E*时，必须在指针上加一个非0的偏移常量dFE。C ++规范要求NULL指针在强制转化后依然为NULL ， 因此在做强制转化需要的运算之前，VC++会检查指针是否为NULL。当然，这个检查只有当指针被显示或者隐式转化为相关类型指针时才进行；当在派生类对 象中调用基类的方法，从而派生类指针在后台被转化为一个基类的Const “this” 指针时，这个检查就不需要进行了，因为在此时，该指针一定不为NULL。

当继承关系中存在虚基类时，强制转化的开销会比较大，具体的说：和访问虚基类成员变量的开销相当。

I *pi;
(G*)pi;    // (G*)pi;   
(H*)pi;    // (H*)(pi ? pi + dIH : 0); 
(C*)pi;     // (C*)(pi ? (pi+dIGvbptr + (*(pi+dIGvbptr))[1]) : 0);  

注：pi是指向I对象的指针，G,H是I的基类，C是G,H的虚基类。

1.强制转化pi为G*时，由于G*和I*的地址相同

2.强制转化pi为H*时，只需要考虑一个常量偏移

3.强制转化pi为C*时，所作的计算和访问虚基类成员变量的开销相同，首先得到G的虚基类表指针，再从虚基类表的第二项中取出G到虚基类C的偏移量，最后根据pi、虚基类表偏移和虚基类C与虚基类表指针之间的偏移计算出C*。

一般说来，当从派生类中访问虚基类成员时，应该先强制转化派生类指针为虚基类指针，然后一直使用虚基类指针来访问虚基类成员变量。这样做，可以避免每次都要计算虚基类地址的开销。

/* before: */             ... pi->c1 ... pi->c1 ...
/* faster: */ C* pc = pi; ... pc->c1 ... pc->c1 ...

注：前者一直使用派生类指针pi，故每次访问c1都有计算虚基类地址的较大开销；后者先将pi转化为虚基类指针pc，故后续调用可以省去计算虚基类地址的开销。

6 成员函数

在C++成员函数只是类范围内的又一个成员，X类每个非静态成员函数都会接受一个特殊的隐藏参数——this指针，指针类型为X* const。该指针在后台初始化为指向成员函数工作与其上的对象。同样，在成员函数体内，成员变量的访问是通过在后台计算与this指针的偏移来进行。

struct P{
    int p1;
    void fp();  //new
    virtual void fvp();  //new
};

P有一个非虚成员函数fp()，以及一个虚成员函数fvp()。很明显，虚成员 函数造成对象实例占用更多内存空间，因为虚成员函数需要虚函数表指针。这一点以后还会谈到。这里要特别指出的是，声明非虚成员函数不会造成任何对象实例的 内存开销。现在，考虑P::fp()的定义。

void P::fp(){    //void P::fp([P *const this])
    ++p1;  //++(this->p1);
}

P:fp()接受一个隐藏的this指针参数，对于每个成员函数的调用，编译器都会自动加上这个参数。同时，注意成员变量访问也许比看起来要代价高昂一些，因为成员变量访问通过this指针进行，在有的 继承层次下，this指针需要调整，所以访问的开销可能会比较大。然而，从另一方面来说，编译器通常会把this指针缓存到寄存器中，所以，成员变量访问 的代价不会比访问局部变量的效率更差。

注：访问局部变量，需要到SP寄存器中得到栈指针，再加上局部变量与栈顶的偏移。在没有虚基类的情况下，如果编译器把this指针缓存到了寄存器中，访问成员变量的过程将与访问局部变量的开销相似。

6.1覆盖成员函数
和成员变量一样，成员函数也会被继承。与成员变量不同的是，通过派生中重新定义基类函数时，一个派生类可以覆盖，也可以说替换基类函数定义。覆盖是静态（根据成员函数的静态类型在编译时决定）还是动态（通过对象指针在运动时态决定），依赖于成员函数是否被声明为“虚函数”。

Q从P继承了成员变量和成员函数。Q声明了fp()，覆盖了P::fp()。Q还声明了fvp()，覆盖了P::fvp()虚函数。Q还声明了新的非虚成员函数fp()，以及新的虚成员函数qvf()。

struct Q:P{
    int q1;
    void fp(); // overrides P::fp   
    void fg();    // new   
    void fvp();    // overrides P::fvp   
    virtual void fvq();
};

对于非虚 的成员函数来说，调用哪个成员函数是在编译 时，根据“->”操作符左边指针表达式的类型静态决定 的。特别地，即使ppq指向Q的实例，ppq->fp()仍然调用的是P::fp()，因为ppq被声明为“P*”。（注意，“->”操作符左边的指针类型决定隐藏的this参数的类型。）

P p; P* pp = &p; Q q; P* ppq = &q; Q* pq = &q;  
pp->pf(); // pp->P::pf(); // P::pf(pp);   
ppq->pf(); // ppq->P::pf(); // P::pf(ppq);   
pq->pf(); // pq->Q::pf(); // Q::pf((P*)pq); （错误!）   
pq->qf(); // pq->Q::qf(); // Q::qf(pq);  

注：标记“错误”处，P*似应为Q*。因为pf非虚函数，而pq的类型为Q*，故应该调用到Q的fp函数上，从而该函数应该要求一个Q* const类型的this指针。

对于虚函数 调用来说，调用哪个成员函数在运行时 决定。不管“->”操作符左边的指针表达式的类型如何，调用的虚函数都是由指针实际指向的实例类型所决定 。比如，尽管ppq的类型是P*，当ppq指向Q的实例时，调用的仍然是Q::pvf()。

pp->fvp();  // pp->P::fvp(); // P::fvp(pp);   
ppq->fvp(); // ppq->Q::fvp(); // Q::fvp((Q*)ppq);   
pq->fvp(); // pq->Q::fvp(); // Q::fvp((P*)pq); （错误！）

注：在错误处，P*似应为Q*。因为fvp是虚函数，pq本来就是Q*，又指向Q的实例，都不应该是P*。

为了实现这种机制，引入了隐藏的vfptr 成员变量。 一个vfptr被加入到类中（如果类中没有的话），该vfptr指向类的虚函数表（vftable）。类中每个虚函数在该类的虚函数表中都占据一项。每项保存一个对于该类适用的虚函数的地址。因此，调用虚函数的过程如下：取得实例的vfptr；通过vfptr得到虚函数表的一项；通过虚函数表该项的函数地址间接调用虚函数。也就是说，在普通函数调用的参数传递、调用、返回指令开销外，虚函数调用还需要额外的开销。

回头再看看P和Q的内存布局，可以发现，VC++编译器把隐藏的vfptr成员变量放在P和Q实例的开始处。这就使虚函数的调用能够尽量快一些。实际上，VC++的实现方式是，保证任何有虚函数的类的第一项永远是vfptr。 这就可能要求在实例布局时，在基类前插入新的vfptr，或者要求在多重继承时，虽然在右边，然而有vfptr的基类放到左边没有vfptr的基类的前面（如下）。

class  CA  
{   int  a;};  
class  CB  
{   int  b;};  
class  CL :  public  CB,  public  CA  
{   int  c;};

对于CL类，它的内存布局是：

int b;int a;int c;

class CA{
    int a;
    virtual void seta(int _a){a=_a}
};

同样继承顺序的CL，内存布局是：

vfptr; int a;int b;int c;

许多C++的实现会共享或者重用从基类继承来的vfptr。比如，Q并不会有一个额外的vfptr，指向一个专门存放新的虚函数qvf()的虚函数表。Qvf项只是简单地追加 到P的虚函数表的末尾。如此一来，单继承的代价就不算高昂。一旦一个实例有vfptr了，它就不需要更多的vfptr。新的派生类可以引入更多的虚函数，这些新的虚函数只是简单地在已存在的，“每类一个”的虚函数表的末尾追加新项。

6.2多重继承下的虚函数

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

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

struct S:P,R{
    int s1;
    void fvp();  //overrides P::fvp and R::fvp;
    void fvr();  //overrides R::fvr();
    void fvs();    //new
};

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

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

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

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

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

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

下一个虚函数S::fvr(),函数覆盖了R::fvr()。因为S::fvr()必须要有一个隐藏S*类型的this参数，但是，也可以用R*来调用fvr().也就是说，R的fvr()虚函数槽可以用这个方式

((R*)ps->fvr()； //(*((R*)ps)->R::vfptr[1])((R*)ps)

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

在debug中，必须对this调整进行补偿。

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

注：调用fvr虚函数时，直角给入R*作为this指针。

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

6.5 调整块

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

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

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

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

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

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

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

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

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

6.5 虚继承下虚函数

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

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

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

struct  U : T {  
   int  u1;  
};  

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

6.6 特殊成员函数

本节讨论编译器合成到特殊成员函数中的隐藏代码。

6.6.1 构造函数和析构函数

正如我们所见，在构造和析构过程中，有时需要初始化一些隐藏的成员变量。最坏的情况下，一个构造函数要执行如下操作：

1 如果是“最终派生类”，初始化vbptr成员变量，调用虚基类的构造函数。

2 调用非虚基类的构造函数

3 调用成员变量的构造函数

4 初始化虚函数表成员变量

5 执行构造函数体中，程序所定义的其他初始化代码

（注意：一个“最终派生类”的实例，一定不是嵌套在其他派生类实例中的基类实例）
所以，如果你有一个包含虚函数的很深的继承层次，即使该继承层次由单继承构成，对象的构造可能也需要很多针对虚函数表的初始化。
反之，析构函数必须按照与构造时严格相反的顺序来“肢解”一个对象。

1 合成并初始化虚函数表成员变量

2 执行析构函数体中，程序定义的而其他析构代码

3 调用成员变量的析构函数（按照相反的顺序）

4 调用直接非虚基类的析构函数（按照相反的顺序）

5 如果是“最终派生类”，调用虚基类的析构函数（按照相反顺序）

有虚基类的类的构造函数接受一个隐藏的“最终派生类 标志”，标示虚基类是否需要初始化。对于析构函数，VC++采用“分层析构模型”，代码中加入一个隐藏的析构函数，该函数被用于析构包含虚基类的类（对于 “最终派生类”实例而言）；代码中再加入另一个析构函数，析构不包含虚基类的类。前一个析构函数调用后一个。

6.6.2 虚析构函数和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操作符。

7 数组

堆上分配空间数组使虚析构函数进一步复杂化。问题变复杂的原因有两个：

1.堆上分配空间的数组，由于数组可大可小，所以，数组大小值应该和数组一起保存。因此，堆上分配空间的数组会分配额外的空间来存储数组元素个数。

2.当数组被删除时，数组中每个元素都要被正确地释放，即使当数组大小不确定时也必须成功完成该操作。然而，派生类可能比基类占用更多的内存空间，从而使正确释放比较困难。

struct  WW : W {  int  w1; };  
pv = new  W[m];  
delete  [] pv;  // delete m W's (sizeof(W) == sizeof(V))   
pv = new  WW[n];  
delete  [] pv;  // delete n WW's (sizeof(WW) > sizeof(V)) 

注：WW从W继承，增加了一个成员变量，因此，WW占用的内存空间比W大。然而，不管指针pv指向W的数组还是WW的数组，delete[]都必须正确地释放WW或W对象占用的内存空间。

虽 然从严格意义上来说，数组delete的多态行为C++标准并未定义，然而，微软有一些客户要求实现该行为。因此，在MSC++中，该行为是用另一个编译 器生成的虚析构帮助函数来完成。该函数被称为“向量delete析构函数”（因其针对特定的类定制，比如WW，所以，它能够遍历数组的每个元素，调用对每 个元素适用的析构函数）。

8 异常处理

异常处理是C++标准委员会工作文件提供的一种机制，通过该机制，一个函数可以通知其调用者“异常”情况的发生，调用者则能据此选择合适的代码来处理异常。该机制在传统的“函数调用返回，检查错误状态代码”方法之外，给程序提供了另一种处理错误的手段。

因为C++是面向对象的语言，很自然地，C++中用对象来表达异常状态。并且，使用何种异常处理也是基于“抛出的”异常对象的静态或动态类型来决定的。不光 如此，既然C++总是保证超出范围的对象能够被正确地销毁，异常实现也必须保证当控制从异常抛出点转换到异常“捕获”点时（栈展开），超出范围的对象能够 被自动、正确地销毁。
考虑如下例子：

struct  X { X(); };  // exception object class   
struct  Z { Z(); ~Z(); };  // class with a destructor   
extern   void  recover( const  X&);  
void  f( int ), g( int );  
  
int  main() {  
   try  {  
      f(0);  
   } catch  ( const  X& rx) {  
      recover(rx);  
   }  
   return  0;  
}  
  
void  f( int  i) {  
   Z z1;  
   g(i);  
   Z z2;  
   g(i-1);  
}  
  
void  g( int  j) {  
   if  (j < 0)  
      throw  X();  
}  

注：X是异常类，Z是带析构函数的工作类，recover是错误处理函数，f和g一起产生异常条件，g实际抛出异常。
这 段程序会抛出异常。在main中，加入了处理异常的try & catch框架，当调用f(0)时，f构造z1，调用g(0)后，再构造z2，再调用g(-1)，此时g发现参数为负，抛出X异常对象。我们希望在某个调 用层次上，该异常能够得到处理。既然g和f都没有建立处理异常的框架，我们就只能希望main函数建立的异常处理框架能够处理X异常对象。实际上，确实如 此。当控制被转移到main中异常捕获点时，从g中的异常抛出点到main中的异常捕获点之间，该范围内的对象都必须被销毁。在本例中，z2和z1应该被 销毁。
谈到异常处理的具体实现方式，一般情况下，在抛出点和捕 获点都使用“表”来表述能够捕获异常对象的类型；并且，实现要保证能够在特定的捕获点真正捕获特定的异常对象；一般地，还要运用抛出的对象来初始化捕获语 句的“实参”。通过合理地选择编码方案，可以保证这些表格不会占用过多的内存空间。
异 常处理的开销到底如何？让我们再考虑一下函数f。看起来f没有做异常处理。f确实没有包含try，catch，或者是throw关键字，因此，我们会猜异 常处理应该对f没有什么影响。错！编译器必须保证一旦z1被构造，而后续调用的任何函数向f抛回了异常，异常又出了f的范围时，z1对象能被正确地销毁。 同样，一旦z2被构造，编译器也必须保证后续抛出异常时，能够正确地销毁z2和z1。
要 实现这些“展开”语意，编译器必须在后台提供一种机制，该机制在调用者函数中，针对调用的函数抛出的异常动态决定异常环境（处理点）。这可能包括在每个函 数的准备工作和善后工作中增加额外的代码，在最糟糕的情况下，要针对每一套对象初始化的情况更新状态变量。例如，上述例子中，z1应被销毁的异常环境当然 与z2和z1都应该被销毁的异常环境不同，因此，不管是在构造z1后，还是继而在构造z2后，VC++都要分别在状态变量中更新（存储）新的值。
所有这些表，函数调用的准备和善后工作，状态变量的更新，都会使异常处理功能造成可观的内存空间和运行速度开销。正如我们所见，即使在没有使用异常处理的函数中，该开销也会发生。
幸运的是，一些编译器可以提供编译选项，关闭异常处理机制。那些不需要异常处理机制的代码，就可以避免这些额外的开销了。

9 小结

在 本文中，我们讨论了许多重要的C++运行实现问题。我们发现，很多美妙的C++语言特性的开销很低，同时，其他一些美妙的特性（译者注：主要是和“虚”字 相关的东西）将造成较大的开销。C++很多实现机制都是在后台默默地为你工作。一般说来，单独看一段代码时，很难衡量这段代码造成的运行时开销，必须把这 段代码放到一个更大的环境中来考察，运行时开销问题才能得到比较明确的答案。