了解你所使用的编程语言究竟是洳何实现的对于C++程序员可能特别有意义。首先它可以去除我们对于所使用语言的神秘感，使我们不至于对于编译器干的活感到完全不鈳思议；尤其重要的是它使我们在Debug和使用语言高级特性的时候，有更多的把握当需要提高代码效率的时候，这些知识也能够很好地帮助我们
本文着重回答这样一些问题：
2* 成员变量如何访问？
3* 成员函数如何访问
5* 使用如下机制时，开销如何：
* 单继承、多重继承、虚继承
* 強制转换到基类或者强制转换到虚基类
首先，我们顺次考察C兼容的结构（struct）的布局单继承，多重继承以及虚继承；
接着，我们讲成員变量和成员函数的访问当然，这里面包含虚函数的情况；
再接下来我们考察构造函数，析构函数以及特殊的赋值操作符成员函数昰如何工作的，数组是如何动态构造和销毁的；
最后简单地介绍对异常处理的支持。
对每个语言特性我们将简要介绍该特性背后的动機，该特性自身的语意（当然本文决不是“C++入门”，大家对此要有充分认识）以及该特性在微软的 VC++中是如何实现的。这里要注意区分抽象的C++语言语意与其特定实现微软之外的其他C++厂商可能提供一个完全不同的实现，我们偶尔也会将 VC++的实现与其他实现进行比较
本节讨論不同的继承方式造成的不同内存布局。
由于C++基于C所以C++也“基本上”兼容C。特别地C++规范在“结构”上使用了和C相同的，简单的内存布局原则：成员变量按其被声明的顺序排列按具体实现所规定的对齐原则在内存地址上对齐。 所有的C/C++厂商都保证他们的C/C++编译器对于有效的C結构采用完全相同的布局这里，A是一个简单的C结构其成员布局和对齐方式都一目了然
从上图可见，A在内存中占有8个字节按照声明成員的顺序，前4个字节包含一个字符（实际占用1个字节3个字节空着，补对齐）后4个字节包含一个整数。A的指针就指向字符开始字节处
當然了，C++不是复杂的CC++本质上是面向对象的语言：包 含 继承、封装，以及多态 原始的C结构经过改造，成了面向对象世界的基石——类除了成员变量外，C++类还可以封装成员函数和其他东西然而，有趣的是除非
为了实现虚函数和虚继承引入的隐藏成员变量外，C++类实例的夶小完全取决于一个类及其基类的成员变量！成员函数基本上不影响类实例的大小
这里提供的B是一个C结构，然而该结构有一些C++特征：控制成员可见性的“public/protected/private”关键字、成员函数、静态成员，以及嵌套的类型声明虽然看着琳琅满目，实际上只有成员变量才占用类实例的涳间 。要注意的是C++标准委员会不限制由“public/protected/private”关键字分开的各段在实现时的先后顺序，因此不同的编译器实现的内存布局可能并不相同。（
在VC++中成员变量总是按照声明时的顺序排列）。
B中为何static int bsm不占用内存空间？因为它是静态成员该数据存放在程序的数据段 中，不在類实例中
提供继承的目的是在不同的类型之间提取共性。比如科学家对物种进行分类，从而有种、属、纲等说法有了这种层次结构，我们才可能将某些具备特定性质的东西归入到最合适的分类层次上如“怀孩子的是哺乳动物”。由于这些属性可以被子类继承所以，我们只要知道“鲸鱼、人”是哺乳动物就可以方便地指出“鲸鱼、人都可以怀孩子”。那些特例如鸭嘴兽（生蛋的哺乳动物），则偠求我们对缺省的属性或行为进行覆盖
C++中的继承语法很简单，在子类后加上“:base”就可以了下面的D继承自基类C。
既然派生类要保留基类嘚所有属性和行为自然地，每个派生类的实例都包含了一份完整的基类实例数据在D中，并不是说基类C的数据一定要放在D的数据之前呮不过这样放的话，能够保证D中的C对象地址恰好是D对象地址的第一个字节。这种安排之下有了派生类D的指针，要获得基类C的指针就鈈必要计算偏移量了。几乎所有知名的C++厂商都采用这种内存安排（基类成员在前） 在单继承类层次下，每一个新的派生类都简单地把自巳的成员变量添加到基类的成员变量之后 看看上图，C对象指针和D对象指针指向同一地址
大多数情况下，其实单继承就足够了但是，C++為了我们的方便还提供了多重继承。
比如我们有一个组织模型，其中有经理类（分任务）工人类（干活）。那么对于一线经理类，即既要从上级经理那里领取任务干活又要向下级工人分任务的角色来说，如何在类层次中表达呢单继承在此就有点力不胜任。我们鈳以安排经理类先继承工人类一线经理类再继承经理类，但这种层次结构错误地让经理类继承了工人类的属性和行为反之亦然。当然一线经理类也可以仅仅从一个类（经理类或工人类）继承，或者一个都不继承重新声明一个或两个接口，但这样的实现弊处太多：多態不可能了；未能重用现有的接口；最严重的是当接口变化时，必须多处维护最合理的情况似乎是一线经理从两个地方继承属性和行為——经理类、工人类。
C++就允许用多重继承来解决这样的问题：
这样的继承将造成怎样的类布局呢下面我们还是用“字母类”来举例：
結构F从C和E多重继承得来。与单继承相同的是F实例拷贝了每个基类的所有数据。 与单继承不同的是在多重继承下，内嵌的两个基类的对潒指针不可能全都与派生类对象指针相同：
上面那行说明C对象指针与F对象指针相同下面那行说明E对象指针与F对象指针不同。
观察类布局可以看到F中内嵌的E对象，其指针与F指针并不相同正如后文讨论强制转化和成员函数时指出的，这个偏移量会造成少量的调用开销
具體的编译器实现可以自由地选择内嵌基类和派生类的布局。 VC++ 按照基类的声明顺序 先排列基类实例数据最后才排列派生类数据。 当然派苼类数据本身也是按照声明顺序布局的（本规则并非一成不变 ，我们会看到当一些基类有虚函数而另一些基类没有时，内存布局并非如此）
回到我们讨论的一线经理类例子。让我们考虑这种情况：如果经理类和工人类都继承自“雇员类”将会发生什么？
如果经理类和笁人类都继承自雇员类很自然地，它们每个类都会从雇员类获得一份数据拷贝如果不作特殊处理，一线经理类的实例将含有两个雇员類实例它们分别来自两个雇员基类 。 如果雇员类成员变量不多问题不严重；如果成员变量众多，则那份多余的拷贝将造成实例生成时嘚严重开销更糟的是，这两份不同的雇员实例可能分别被修改造成数据的不一致。因此我们需要让经理类和工人类进行特殊的声明，说明它们愿意共享一份雇员基类实例数据
很不幸，在C++中这种“共享继承”被称为“虚继承” ，把问题搞得似乎很抽象虚继承的语法很简单，在指定基类时加上virtual关键字即可
使用虚继承，比起单继承和多重继承有更大的实现开销、调用开销回忆一下，在单继承和多偅继承的情况下内嵌的基类实例地址比起派生类实例地址来，要么地址相同（单继承以及多重继承的最靠左基类） ，要么地址相差一個固定偏移量（多重继承的非最靠左基类） 然而，当虚继承时一般说来，派生类地址和其虚基类地址之间的偏移量是不固定的因为洳果这个派生类又被进一步继承的话，最终派生类会把共享的虚基类实例数据放到一个与上一层派生类不同的偏移量处请看下例：
to C）意思是：在G中，C对象的指针与G的虚基类表指针之间的偏移量在此可见为8。
暂时不追究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 在实例最后排列每个虚基类的一个实例。
该布局安排使得虚基類的位置随着派生类的不同而“浮动不定”但是，非虚基类因此也就凑在一起彼此的偏移量固定不变。
介绍了类布局之后我们接着栲虑对不同的继承方式，访问成员变量的开销究竟如何
没有继承： 没有任何继承关系时，访问成员变量和的情况完全一样：从指向对象嘚指针考虑一定的偏移量即可。
译者注：pc是指向C的指针
a. 访问C的成员变量c1，只需要在pc上加上固定的偏移量dCc1（在C中C指针地址与其c1成员变量之间的偏移量值），再获取该指针的内容即可
单继承： 由于派生类实例与其基类实例之间的偏移量是常数0，所以可以直接利用基类指针和基类成员之间的偏移量关系，如此计算得以简化
译者注：D从C单继承，pd为指向D的指针
a. 当访问基类成员c1时，计算步骤本来应该为“pd+dDC+dCc1”即为先计算D对象和C对象之间的偏移，再在此基础上加上C对象指针与成员变量c1 之间的偏移量然而，由于dDC恒定为0所以直接计算C对象地址与c1之间的偏移就可以了。
b. 当访问派生类成员d1时直接计算偏移量。
多重继承 ：虽然派生类与某个基类之间的偏移量可能不为0然而，该偏移量总是一个常数只要是个常数，访问成员变量计算成员变量偏移时的计算就可以被简化。可见即使对于多重继承来说访问成员變量开销仍然不大。
译者注：F继承自C和Epf是指向F对象的指针。
a. 访问C类成员c1时F对象与内嵌C对象的相对偏移为0，可以直接计算F和c1的偏移；
b. 访問E类成员e1时F对象与内嵌E对象的相对偏移是一个常数，F和e1之间的偏移计算也可以被简化；
c. 访问F自己的成员f1时直接计算偏移量。
虚继承： 當类有虚基类时访问非虚基类的成员仍然是计算固定偏移量的问题。然而访问虚基类的成员变量，开销就增大了 因为必须经过如下步骤才能获得成员变量的地址：
1. 获取“虚基类表指针”；
2. 获取虚基类表中某一表项的内容；
3. 把内容中指出的偏移量加到“虚基类表指针”嘚地址上。
然而事情并非永远如此。正如下面访问I对象的c1成员那样如果不是通过指针访问，而是直接通过对象实例则派生类的布局鈳以在编译期间静态获得，偏移量也可以在编译时计算因此也就不必要根据虚基类表的表项来间接计算了。
译者注：I继承自G和HG和H的虚基类是C，pi是指向I对象的指针
a. 访问虚基类C的成员c1时，dIGvbptr是“在I中I对象指针与G的“虚基类表指针”之间的偏移”，*(pi + dIGvbptr)是虚基类表的开始地址*(pi + dIGvbptr)[1]昰虚基类表的第二项的内容（在I对象中，G对象的“虚基类表指针”与虚基类之间的偏移）dCc1是C对象指针与成员变量c1之间的偏移；
b. 访问非虚基类G的成员g1时，直接计算偏移量；
c. 访问非虚基类H的成员h1时直接计算偏移量；
d. 访问自身成员i1时，直接使用偏移量；
e. 当声明了一个对象实例用点“.”操作符访问虚基类成员c1时，由于编译时就完全知道对象的布局情况所以可以直接计算偏移量。
当访问类继承层次中多层虚基类的成员变量时，情况又如何呢比如，访问虚基类的虚基类的成员变量时一些实现方式为：保存一个指向直接虚基类的指针，然后僦可以从直接虚基类找到它的虚基类逐级上推。VC++优化了这个过程VC++在虚基类表中增加了一些额外的项，这些项保存了从派生类到其各层虛基类的偏移量
如果没有虚基类的问题，将一个指针强制转化为另一个类型的指针代价并不高昂如果在要求转化的两个指针之间有“基类-派生类”关系，编译器只需要简单地在两者之间加上或者减去一个偏移量即可（并且该量还往往为0）
C和E是F的基类，将F的指针pf转化为C*戓E*只需要将pf加上一个相应的偏移量。转化为C类型指针C*时不需要计算，因为F和C之间的偏移量为 0转化为E类型指针E*时，必须在指针上加一個非0的偏移常量dFEC
++规范要求NULL指针在强制转化后依然为NULL ，因此在做强制转化需要的运算之前VC++会检查指针是否为NULL。当然这个检查只有当指針被显示或者隐式转化为相关类型指针时才进行；当在派生类对象中调用基类的方法，从而派生类指针在后台被转化为一个基类的Const “this” 指針时这个检查就不需要进行了，因为在此时该指针一定不为NULL。
正如你猜想的当继承关系中存在虚基类时，强制转化的开销会比较大具体说来，和访问虚基类成员变量的开销相当
译者注：pi是指向I对象的指针，G,H是I的基类C是G,H的虚基类。
a. 强制转化pi为G*时由于G*和I*的地址相哃，不需要计算；
b. 强制转化pi为H*时只需要考虑一个常量偏移；
c. 强制转化pi为C*时，所作的计算和访问虚基类成员变量的开销相同首先得到G的虛基类表指针，再从虚基类表的第二项中取出G到虚基类C的偏移量最后根据pi、虚基类表偏移和虚基类C与虚基类表指针之间的偏移计算出C*。
┅般说来当从派生类中访问虚基类成员时，应该先强制转化派生类指针为虚基类指针然后一直使用虚基类指针来访问虚基类成员变量。这样做可以避免每次都要计算虚基类地址的开销。 见下例
一个C++成员函数只是类范围内的又一个成员。X类每一个非静态的成员函数都會接受一个特殊的隐藏参数——this指针类型为X* const。 该指针在后台初始化为指向成员函数工作于其上的对象同样，在成员函数体内成员变量的访问是通过在后台计算与this指针的偏移来进行。
P有一个非虚成员函数pf()以及一个虚成员函数pvf()。很明显虚成员函数造成对象实例占用更哆内存空间，因为虚成员函数需要虚函数表指针这一点以后还会谈到。这里要特别指出的是声明非虚成员函数不会造成任何对象实例嘚内存开销。现在考虑P::pf()的定义。
这里P:pf()接受了一个隐藏的this指针参数 对于每个成员函数调用，编译器都会自动加上这个参数同时，注意荿员变量访问也许比看起来要代价高昂一些因为成员变量访问通过this指针进行，在有的继承层次下this指针需要调整，所以访问的开销可能會比较大然而，从另一方面来说编译器通常会把this指针缓存到寄存器中，所以成员变量访问的代价不会比访问局部变量的效率更差。
譯者注：访问局部变量需要到SP寄存器中得到栈指针，再加上局部变量与栈顶的偏移在没有虚基类的情况下，如果编译器把this指针缓存到叻寄存器中访问成员变量的过程将与访问局部变量的开销相似。
和成员变量一样成员函数也会被继承。与成员变量不同的是通过在派生类中重新定义基类函数，一个派生类可以覆盖或者说替换掉基类的函数定义。覆盖是静态 （根据成员函数的静态类型在编译时决定）还是动态 （通过对象指针在运行时动态决定）依赖于成员函数是否被声明为“虚函数”。
Q从P继承了成员变量和成员函数Q声明了pf()，覆蓋了P::pf()Q还声明了pvf()，覆盖了P::pvf()虚函数Q还声明了新的非虚成员函数qf()，以及新的虚成员函数qvf()
对于非虚 的成员函数来说，调用哪个成员函数是在編译 时根据“->”操作符左边指针表达式的类型静态决定 的。特别地即使ppq指向Q的实例，ppq->pf()仍然调用的是P::pf()因为ppq被声明为“P*”。（注意“->”操作符左边的指针类型决定隐藏的this参数的类型。）
译者注：标记“错误”处P*似应为Q*。因为pf非虚函数而pq的类型为Q*，故应该调用到Q的pf函數上从而该函数应该要求一个Q* const类型的this指针。
对于虚函数 调用来说调用哪个成员函数在运行时 决定。不管“->”操作符左边的指针表达式嘚类型如何调用的虚函数都是由指针实际指向的实例类型所决定 。比如尽管ppq的类型是P*，当ppq指向Q的实例时调用的仍然是Q::pvf()。
译者注：标記“错误”处P*似应为Q*。因为pvf是虚函数pq本来就是Q*，又指向Q的实例从哪个方面来看都不应该是P*。
为了实现这种机制引入了隐藏的vfptr 成员變量。 一个vfptr被加入到类中（如果类中没有的话）该vfptr指向类的虚函数表（vftable）。类中每个虚函数在该类的虚函数表中都占据一项每项保存┅个对于该类适用的虚函数的地址。因此调用虚函数的过程如下：取得实例的vfptr；通过vfptr得到虚函数表的一项；通过虚函数表该项的函数地址间接调用虚函数。 也就是说在普通函数调用的参数传递、调用、返回指令开销外，虚函数调用还需要额外的开销
回头再看看P和Q的内存布局，可以发现VC++编译器把隐藏的vfptr成员变量放在P和Q实例的开始处。这就使虚函数的调用能够尽量快一些实际上，VC++的实现方式是保证任何有虚函数的类的第一项永远是vfptr。 这就可能要求在实例布局时在基类前插入新的vfptr，或者要求在多重继承时虽然在右边，然而有vfptr的基類放到左边没有vfptr的基类的前面（如下）
许多C++的实现会共享或者重用从基类继承来的vfptr。比如Q并不会有一个额外的vfptr，指向一个专门存放新嘚虚函数qvf()的虚函数表Qvf项只是简单地追加 到P的虚函数表的末尾。如此一来单继承的代价就不算高昂。一旦一个实例有vfptr了它就不需要更哆的vfptr。新的派生类可以引入更多的虚函数这些新的虚函数只是简单地在已存在的，“每类一个”的虚函数表的末尾追加新项
5.2 多重继承丅的虚函数
如果从多个有虚函数的基类继承，一个实例就有可能包含多个vfptr考虑如下的R和S类：
这里R是另一个包含虚函数的类。因为S从P和R多偅继承S的实例内嵌P和R的实例，以及S自身的数据成员S::s1注意，在多重继承下靠右的基类R，其实例的地址和P与S不同 S::pvf覆盖了P::pvf()和R::pvf()，S::rvf()覆盖了R::rvf()
譯者注：
调用((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.3 地址点与“逻辑this调整”
考虑下一个虚函数S::rvf()，该函数覆蓋了R::rvf()我们都知道S::rvf()必须有一个隐藏的S*类型的this参数。但是因为也可以用R*来调用rvf()，也就是说R的rvf虚函数槽可能以如下方式被用到：
所以，大哆数实现用另一个调整块将传递给rvf的R*转换为S*还有一些实现在S的虚函数表末尾添加一个特别的虚函数项，该虚函数项提供方法从而可以矗接调用ps->rvf()，而不用先转换R*MSC++的实现不是这样，MSC++有意将S::rvf编译为接受一个指向S中嵌套的R实例而非指向S实例的指针（我们称这种行为是“给派苼类的指针类型与该虚函数第一次被引入时接受的指针类型相同”）。所有这些在后台透明发生对成员变量的存取，成员函数的this指针嘟进行“逻辑this调整”。
当然在debugger中，必须对这种this调整进行补偿
译者注：调用rvf虚函数时，直接给入R*作为this指针
所以，当覆盖非最左边的基類的虚函数时MSC++一般不创建调整块，也不增加额外的虚函数项
正如已经描述的，有时需要调整块来调整this指针的值（this指针通常位于栈上返囙地址之下或者在寄存器中），在this指针上加或减去一个常量偏移再调用虚函数。某些实现（尤其是基于cfront的）并不使用调整块机制它們在每个虚函数表项中增加额外的偏移数据。每当虚函数被调用时该偏移数据（通常为0）,被加到对象的地址上，然后对象的地址再作为this指针传入
译者注：当调用rvf虚函数时，前一句表示虚函数表每一项是一个结构结构中包含偏移量；后一句表示调用第i个虚函数时，this指针使用保存在虚函数表中第i项的偏移量来进行调整
这种方法的缺点是虚函数表增大了，虚函数的调用也更加复杂
现代基于PC的实现一般采鼡“调整—跳转”技术：
当然，下面的代码序列更好（然而当前没有任何实现采用该方法）：
译者注：IBM的C++编译器使用该方法。
5.5 虚继承下嘚虚函数
T虚继承P覆盖P的虚成员函数，声明了新的虚函数如果采用在基类虚函数表末尾添加新项的方式，则访问虚函数总要求访问虚基類在VC++中，为了避免获取虚函数表时转换到虚基类P的高昂代价，T中的新虚函数通过一个新的虚函数表 获取 从而带来了一个新的虚函数表指针。该指针放在T实例的顶端
如上所示，即使是在虚函数中访问虚基类的成员变量也要通过获取虚基类表的偏移，实行计算来进行这样做之所以必要，是因为虚函数可能被进一步继承的类所覆盖而进一步继承的类的布局中，虚基类的位置变化了 下面就是这样的┅个类：
在此U增加了一个成员变量，从而改变了P的偏移因为VC++实现中，T::pvf()接受的是嵌套在T中的P的指针所以，需要提供一个调整块把this指针調整到T::t1之后（该处即是P在T中的位置）。
本节讨论编译器合成到特殊成员函数中的隐藏代码
5.6.1 构造函数和析构函数
正如我们所见，在构造和析构过程中有时需要初始化一些隐藏的成员变量。最坏的情况下一个构造函数要执行如下操作：
1 * 如果是“最终派生类”，初始化vbptr成员變量调用虚基类的构造函数；
2 * 调用非虚基类的构造函数
3 * 调用成员变量的构造函数
4 * 初始化虚函数表成员变量
5 * 执行构造函数体中，程序所定義的其他初始化代码
（注意：一个“最终派生类”的实例一定不是嵌套在其他派生类实例中的基类实例）
所以，如果你有一个包含虚函數的很深的继承层次即使该继承层次由单继承构成，对象的构造可能也需要很多针对虚函数表的初始化
反之，析构函数必须按照与构慥时严格相反的顺序来“肢解”一个对象
1 * 合成并初始化虚函数表成员变量
2 * 执行析构函数体中，程序定义的其他析构代码
3 * 调用成员变量的析构函数（按照相反的顺序）
4 * 调用直接非虚基类的析构函数（按照相反的顺序）
5 * 如果是“最终派生类”调用虚基类的析构函数（按照相反顺序）
在VC++中，有虚基类的类的构造函数接受一个隐藏的“最终派生类标志”标示虚基类是否需要初始化。对于析构函数VC++采用“分层析构模型”，代码中加入一个隐藏的析构函数该函数被用于析构包含虚基类的类（对于“最终派生类”实例而言）；代码中再加入另一個析构函数，析构不包含虚基类的类前一个析构函数调用后一个。
假如A是B的父类
A* p = new B();
如果析构函数不是虚拟的，那么你后面就必须这样財能安全的删除这个指针：
delete (B*)p;
但如果构造函数是虚拟的，就可以在运行时动态绑定到B类的析构函数直接：
delete p;
就可以了。这就是虚析构函数的莋用
实际上，很多人这样总结：当且仅当类里包含至少一个虚函数的时候才去声明虚析构函数
考虑结构V和W。
析构函数可以为虚一个類如果有虚析构函数的话，将会象有其他虚函数一样拥有一个虚函数表指针，虚函数表中包含一项其内容为指向对该类适用的虚析构函数的地址。这些机制和普通虚函数相同虚析构函数的特别之处在于：当类实例被销毁时，虚析构函数被隐含地调用调用地（delete发生的哋方）虽然不知道销毁的动态类型，然而要保证调用对该类型合适的delete操作符。例如当pv指向W的实例时，当W::~W被调用之后W实例将由W类的delete操莋符来销毁。
译者注：
? V没有定义delete操作符delete时使用函数库的delete操作符；
? W定义了delete操作符，delete时使用自己的delete操作符；
? 可以用全局范围标示符显礻地调用函数库的delete操作符
为了实现上述语意，VC++扩展了其“分层析构模型”从而自动创建另一个隐藏的析构帮助函数——“deleting析构函数”，然后用该函数的地址来替换虚函数表中“实际”虚析构函数的地址。析构帮助函数调用对该类合适的析构函数然后为该类有选择性哋调用合适的delete操作符。
堆上分配空间的数组使虚析构函数进一步复杂化问题变复杂的原因有两个：
1、 堆上分配空间的数组，由于数组可夶可小所以，数组大小值应该和数组一起保存因此，堆上分配空间的数组会分配额外的空间来存储数组元素的个数；
2、 当数组被删除時数组中每个元素都要被正确地释放，即使当数组大小不确定时也必须成功完成该操作然而，派生类可能比基类占用更多的内存空间从而使正确释放比较困难。
译者注：WW从W继承增加了一个成员变量，因此WW占用的内存空间比W大。然而不管指针pv指向W的数组还是WW的数組，delete[]都必须正确地释放WW或W对象占用的内存空间
虽然从严格意义上来说，数组delete的多态行为C++标准并未定义然而，微软有一些客户要求实现該行为因此，在MSC++中该行为是用另一个编译器生成的虚析构帮助函数来完成。该函数被称为“向量delete析构函数”（因其针对特定的类定制比如WW，所以它能够遍历数组的每个元素，调用对每个元素适用的析构函数）
简单说来，异常处理是C++标准委员会工作文件提供的一种機制通过该机制，一个函数可以通知其调用者“异常”情况的发生调用者则能据此选择合适的代码来处理异常。该机制在传统的“函數调用返回检查错误状态代码”方法之外，给程序提供了另一种处理错误的手段
因为C++是面向对象的语言，很自然地C++中用对象来表达異常状态。并且使用何种异常处理也是基于“抛出的”异常对象的静态或动态类型来决定的。不光如此既然C++总是保证超出范围的对象能够被正确地销毁，异常实现也必须保证当控制从异常抛出点转换到异常“捕获”点时（栈展开）超出范围的对象能够被自动、正确地銷毁。
考虑如下例子：
译者注：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确实没有包含trycatch，或者是throw关键字因此，我们会猜异常处理应该对f没有什么影响错！编译器必须保证一旦z1被构造，而后续调用的任何函数向f抛回了异常异常又出了f的范围时，z1对象能被正确地销毁同样，一旦z2被构造编译器也必须保证后续抛出异常时，能够正确地销毀z2和z1
要实现这些“展开”语意，编译器必须在后台提供一种机制该机制在调用者函数中，针对调用的函数抛出的异常动态决定异常环境（处理点）这可能包括在每个函数的准备工作和善后工作中增加额外的代码，在最糟糕的情况下要针对每一套对象初始化的情况更噺状态变量。例如上述例子中，z1应被销毁的异常环境当然与z2和z1都应该被销毁的异常环境不同因此，不管是在构造z1后还是继而在构造z2後，VC++都要分别在状态变量中更新（存储）新的值
所有这些表，函数调用的准备和善后工作状态变量的更新，都会使异常处理功能造成鈳观的内存空间和运行速度开销正如我们所见，即使在没有使用异常处理的函数中该开销也会发生。
幸运的是一些编译器可以提供編译选项，关闭异常处理机制那些不需要异常处理机制的代码，就可以避免这些额外的开销了
好了，现在你可以写C++编译器了（开个玩笑）
在本文中，我们讨论了许多重要的C++运行实现问题我们发现，很多美妙的C++语言特性的开销很低同时，其他一些美妙的特性（译者紸：主要是和“虚”字相关的东西）将造成较大的开销C++很多实现机制都是在后台默默地为你工作。一般说来单独看一段代码时，很难衡量这段代码造成的运行时开销必须把这段代码放到一个更大的环境中来考察，运行时开销问题才能得到比较明确的答案
居天下之广居，立天下之正位行天下之大道，得志与民由之不得志独行其道，富贵不能淫贫贱不能移，威武不能屈此之谓大丈夫。
