c++继承中的内存布局

今天在网上看到了一篇写得非常好的文章，是有关c++类继承内存布局的。看了之后获益良多，现在转在我自己的博客里面，作为以后复习之用。

——谈VC++对象模型

（美）简.格雷

程化 译

译者前言

一个C++程序员，想要进一步提升技术水平的话，应该多了解一些语言的语意细节。对于使用VC++的程序员来说，还应该了解一些VC++对于C++的诠释。 Inside the C++ Object Model虽然是一本好书，然而，书的篇幅多一些，又和具体的VC++关系小一些。因此，从篇幅和内容来看，译者认为本文是深入理解C++对象模型比较好的一个出发点。

这篇文章以前看到时就觉得很好，旧文重读，感觉理解得更多一些了，于是产生了翻译出来，与大家共享的想法。虽然文章不长，但时间有限，又若干次在翻译时打盹睡着，拖拖拉拉用了小一个月。

一方面因本人水平所限，另一方面因翻译时经常打盹，错误之处恐怕不少，欢迎大家批评指正。

本文原文出处为MSDN。如果你安装了MSDN，可以搜索到C++ Under the Hood。否则也可在网站上找到http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/jangrayhood.asp。

1 前言

了解你所使用的编程语言究竟是如何实现的，对于C++程序员可能特别有意义。首先，它可以去除我们对于所使用语言的神秘感，使我们不至于对于编译器干的活感到完全不可思议；尤其重要的是，它使我们在Debug和使用语言高级特性的时候，有更多的把握。当需要提高代码效率的时候，这些知识也能够很好地帮助我们。

本文着重回答这样一些问题：

1* 类如何布局？

2* 成员变量如何访问？

3* 成员函数如何访问？

4* 所谓的“调整块”（adjuster thunk）是怎么回事？

5* 使用如下机制时，开销如何：

* 单继承、多重继承、虚继承

* 虚函数调用

* 强制转换到基类，或者强制转换到虚基类

* 异常处理

首先，我们顺次考察C兼容的结构（struct）的布局，单继承，多重继承，以及虚继承；

接着，我们讲成员变量和成员函数的访问，当然，这里面包含虚函数的情况；

再接下来，我们考察构造函数，析构函数，以及特殊的赋值操作符成员函数是如何工作的，数组是如何动态构造和销毁的；

最后，简单地介绍对异常处理的支持。

对每个语言特性，我们将简要介绍该特性背后的动机，该特性自身的语意（当然，本文决不是“C++入门”，大家对此要有充分认识），以及该特性在微软的 VC++中是如何实现的。这里要注意区分抽象的C++语言语意与其特定实现。微软之外的其他C++厂商可能提供一个完全不同的实现，我们偶尔也会将 VC++的实现与其他实现进行比较。

2 类布局

本节讨论不同的继承方式造成的不同内存布局。

2.1 C结构（struct）

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





view plaincopy
to clipboardprint?

struct A {
char c;
int i;
};

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

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

译者注：B中，为何static int bsm不占用内存空间？因为它是静态成员，该数据存放在程序的数据段中，不在类实例中。

2.3 单继承

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

C++中的继承语法很简单，在子类后加上“:base”就可以了。下面的D继承自基类C。





struct C {

int c1;
void cf();
};

struct D : C {

int d1;
void df();
};

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

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

2.4 多重继承

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

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

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

struct Manager ... { ... };

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

struct E {

int e1;
void ef();
};

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

struct F : C, E {

int f1;
void ff();
};

F f;

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

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

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

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

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

2.5 虚继承

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

struct Employee { ... };

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

struct Employee { ... };

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

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

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





struct G : virtual C {

int g1;
void gf();
};

struct H : virtual C {

int h1;
void hf();
};

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

struct I : G, H {

int i1;
void _if();
};

C* pc;

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

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

译者注：pc是指向C的指针。

a. 访问C的成员变量c1，只需要在pc上加上固定的偏移量dCc1（在C中，C指针地址与其c1成员变量之间的偏移量值），再获取该指针的内容即可。

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

D* pd;

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

F* pf;

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

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对象的指针。

a. 访问C类成员c1时，F对象与内嵌C对象的相对偏移为0，可以直接计算F和c1的偏移；

b. 访问E类成员e1时，F对象与内嵌E对象的相对偏移是一个常数，F和e1之间的偏移计算也可以被简化；

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

虚继承：
当类有虚基类时，访问非虚基类的成员仍然是计算固定偏移量的问题。然而，访问虚基类的成员变量，开销就增大了 ，因为必须经过如下步骤才能获得成员变量的地址：

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

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

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

然而，事情并非永远如此。正如下面访问I对象的c1成员那样，如果不是通过指针访问，而是直接通过对象实例，则派生类的布局可以在编译期间静态获得，偏移量也可以在编译时计算，因此也就不必要根据虚基类表的表项来间接计算了。

I* pi;

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

F* pf;

(C*)pf; // (C*)(pf ? pf + dFC : 0); // (C*)pf;
(E*)pf; // (E*)(pf ? pf + dFE : 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);

struct P {

int p1;
void pf(); // new
virtual void pvf(); // new
};

struct P {
int p1;
void pf(); // new
virtual void pvf(); // new
};

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

void P::pf() { // void P::pf([P *const this])

++p1; // ++(this->p1);
}

int q1;

void pf(); // overrides P::pf
void qf(); // new
void pvf(); // overrides P::pvf
virtual void qvf(); // new
};

struct Q : P {
int q1;
void pf(); // overrides P::pf
void qf(); // new
void pvf(); // overrides P::pvf
virtual void qvf(); // new
};

对于非虚 的成员函数来说，调用哪个成员函数是在编译时，根据“->”操作符左边指针表达式的类型静态决定
的。特别地，即使ppq指向Q的实例，ppq->pf()仍然调用的是P::pf()，因为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);

pp->pvf(); // pp->P::pvf(); // P::pvf(pp);

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

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

译者注：标记“错误”处，P*似应为Q*。因为pvf是虚函数，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;};

class CA

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

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。新的派生类可以引入更多的虚函数，这些新的虚函数只是简单地在已存在的，“每类一个”的虚函数表的末尾追加新项。

5.2 多重继承下的虚函数

如果从多个有虚函数的基类继承，一个实例就有可能包含多个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
};

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()

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

((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)

ps->rvf();

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

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() { ... }

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

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

5.5 虚继承下的虚函数

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;
};

struct U : T {
int u1;
};

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

5.6 特殊成员函数

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

5.6.1 构造函数和析构函数

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

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

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

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

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

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

（注意：一个“最终派生类”的实例，一定不是嵌套在其他派生类实例中的基类实例）

所以，如果你有一个包含虚函数的很深的继承层次，即使该继承层次由单继承构成，对象的构造可能也需要很多针对虚函数表的初始化。

反之，析构函数必须按照与构造时严格相反的顺序来“肢解”一个对象。

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

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

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

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

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

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

5.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();
};

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()

struct WW : W { int w1; };

pv = new W[m];
delete [] pv; // delete m W's (sizeof(W) == sizeof(V))
pv = new WW
;
delete [] pv; // delete n WW's (sizeof(WW) > sizeof(V))

struct WW : W { int w1; };
pv = new W[m];
delete [] pv; // delete m W's (sizeof(W) == sizeof(V))
pv = new WW
;
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，所以，它能够遍历数组的每个元素，调用对每个元素适用的析构函数）。

7 异常处理

简单说来，异常处理是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();
}

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++都要分别在状态变量中更新（存储）新的值。

所有这些表，函数调用的准备和善后工作，状态变量的更新，都会使异常处理功能造成可观的内存空间和运行速度开销。正如我们所见，即使在没有使用异常处理的函数中，该开销也会发生。

幸运的是，一些编译器可以提供编译选项，关闭异常处理机制。那些不需要异常处理机制的代码，就可以避免这些额外的开销了。

8 小结

好了，现在你可以写C++编译器了（开个玩笑）。

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