C++深解(29页).doc

《C++深解(29页).doc》由会员分享，可在线阅读，更多相关《C++深解(29页).doc（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、-一个C+成员函数只是类范围内的又一个成员。X类每一个非静态的成员函数都会接受一个特殊的隐藏参数this指针，类型为X* const。该指针在后台初始化为指向成员函数工作于其上的对象。同样，在成员函数体内，成员变量的访问是通过在后台计算与this指针的偏移来进行。struct P int p1; void pf(); / new virtual void pvf(); / new;P有一个非虚成员函数pf()，以及一个虚成员函数pvf()。很明显，虚成员函数造成对象实例占用更多内存空间，因为虚成员函数需要虚函数表指针。这一点以后还会谈到。这里要特别指出的是，声明非虚成员函数不会造成任何对象实例

2、的内存开销。现在，考虑P:pf()的定义。void P:pf() / void P:pf(P *const this) +p1; / +(this-p1);这里P:pf()接受了一个隐藏的this指针参数，对于每个成员函数调用，编译器都会自动加上这个参数。同时，注意成员变量访问也许比看起来要代价高昂一些，因为成员变量访问通过this指针进行，在有的继承层次下，this指针需要调整，所以访问的开销可能会比较大。然而，从另一方面来说，编译器通常会把this指针缓存到寄存器中，所以，成员变量访问的代价不会比访问局部变量的效率更差。译者注：访问局部变量，需要到SP寄存器中得到栈指针，再加上局部变量与栈

3、顶的偏移。在没有虚基类的情况下，如果编译器把this指针缓存到了寄存器中，访问成员变量的过程将与访问局部变量的开销相似。5.1 覆盖成员函数和成员变量一样，成员函数也会被继承。与成员变量不同的是，通过在派生类中重新定义基类函数，一个派生类可以覆盖，或者说替换掉基类的函数定义。覆盖是静态（根据成员函数的静态类型在编译时决定）还是动态（通过对象指针在运行时动态决定），依赖于成员函数是否被声明为“虚函数”。Q从P继承了成员变量和成员函数。Q声明了pf()，覆盖了P:pf()。Q还声明了pvf()，覆盖了P:pvf()虚函数。Q还声明了新的非虚成员函数qf()，以及新的虚成员函数qvf()。struc

4、t 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-

5、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的pf函数上，从而该函数应该要求一个Q* const类型的this指针。对于虚函数调用来说，调用哪个成员函数在运行时决定。不管“-”操作符左边的指针表达式的类型如何，调用的虚函数都是由指针实际指向的实例类型所决定。比如，尽管p

6、pq的类型是P*，当ppq指向Q的实例时，调用的仍然是Q:pvf()。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）。类中每个虚函数

7、在该类的虚函数表中都占据一项。每项保存一个对于该类适用的虚函数的地址。因此，调用虚函数的过程如下：取得实例的vfptr；通过vfptr得到虚函数表的一项；通过虚函数表该项的函数地址间接调用虚函数。也就是说，在普通函数调用的参数传递、调用、返回指令开销外，虚函数调用还需要额外的开销。回头再看看P和Q的内存布局，可以发现，VC+编译器把隐藏的vfptr成员变量放在P和Q实例的开始处。这就使虚函数的调用能够尽量快一些。实际上，VC+的实现方式是，保证任何有虚函数的类的第一项永远是vfptr。这就可能要求在实例布局时，在基类前插入新的vfptr，或者要求在多重继承时，虽然在右边，然而有vfptr的基类

8、放到左边没有vfptr的基类的前面。许多C+的实现会共享或者重用从基类继承来的vfptr。比如，Q并不会有一个额外的vfptr，指向一个专门存放新的虚函数qvf()的虚函数表。Qvf项只是简单地追加到P的虚函数表的末尾。如此一来，单继承的代价就不算高昂。一旦一个实例有vfptr了，它就不需要更多的vfptr。新的派生类可以引入更多的虚函数，这些新的虚函数只是简单地在已存在的，“每类一个”的虚函数表的末尾追加新项。5.2 多重继承下的虚函数如果从多个有虚函数的基类继承，一个实例就有可能包含多个vfptr。考虑如下的R和S类：struct R int r1; virtual void pvf();

9、 / 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(

10、); / (*(P*)ps)-P:vfptr0)(S*)(P*)ps)(R*)ps)-pvf(); / (*(R*)ps)-R:vfptr0)(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的虚函数表中，相应的项也应该被覆盖。然而，我们很快注意到，

11、不光可以用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+实现中，对于有虚函数的多重继承，只有当派生类

12、虚函数覆盖了多个基类的虚函数时，才使用调整块。5.3 地址点与“逻辑this调整”考虑下一个虚函数S:rvf()，该函数覆盖了R:rvf()。我们都知道S:rvf()必须有一个隐藏的S*类型的this参数。但是，因为也可以用R*来调用rvf()，也就是说，R的rvf虚函数槽可能以如下方式被用到：(R*)ps)-rvf(); / (*(R*)ps)-R:vfptr1)(R*)ps)所以，大多数实现用另一个调整块将传递给rvf的R*转换为S*。还有一些实现在S的虚函数表末尾添加一个特别的虚函数项，该虚函数项提供方法，从而可以直接调用ps-rvf()，而不用先转换R*。MSC+的实现不是这样，MSC

13、+有意将S:rvf编译为接受一个指向S中嵌套的R实例，而非指向S实例的指针（我们称这种行为是“给派生类的指针类型与该虚函数第一次被引入时接受的指针类型相同”）。所有这些在后台透明发生，对成员变量的存取，成员函数的this指针，都进行“逻辑this调整”。当然，在debugger中，必须对这种this调整进行补偿。ps-rvf(); / (R*)ps)-rvf(); / S:rvf(R*)ps)译者注：调用rvf虚函数时，直接给入R*作为this指针。所以，当覆盖非最左边的基类的虚函数时，MSC+一般不创建调整块，也不增加额外的虚函数项。5.4 调整块正如已经描述的，有时需要调整块来调整this

14、指针的值（this指针通常位于栈上返回地址之下，或者在寄存器中），在this指针上加或减去一个常量偏移，再调用虚函数。某些实现（尤其是基于cfront的）并不使用调整块机制。它们在每个虚函数表项中增加额外的偏移数据。每当虚函数被调用时，该偏移数据（通常为0）,被加到对象的地址上，然后对象的地址再作为this指针传入。ps-rvf();/ struct void (*pfn)(void*); size_t disp; ;/ (*ps-vfptri.pfn)(ps + ps-vfptri.disp);译者注：当调用rvf虚函数时，前一句表示虚函数表每一项是一个结构，结构中包含偏移量；后一句表示调用

15、第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+编译器使用该方法。5.5 虚继承下的虚函数T虚继承P，覆盖P的虚成员函数，声明了新的虚函数。如果采用在基类虚函数表末尾添加新项的方式，则访问虚

16、函数总要求访问虚基类。在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+;如上所示，即使是在虚函数中，访问虚基类的成员变量也要通过获取虚基类表的偏移，实行计算来进行。这样做之所以必要，是

17、因为虚函数可能被进一步继承的类所覆盖，而进一步继承的类的布局中，虚基类的位置变化了。下面就是这样的一个类：struct U : T int u1;在此U增加了一个成员变量，从而改变了P的偏移。因为VC+实现中，T:pvf()接受的是嵌套在T中的P的指针，所以，需要提供一个调整块，把this指针调整到T:t1之后（该处即是P在T中的位置）。5.6 特殊成员函数本节讨论编译器合成到特殊成员函数中的隐藏代码。5.6.1 构造函数和析构函数正如我们所见，在构造和析构过程中，有时需要初始化一些隐藏的成员变量。最坏的情况下，一个构造函数要执行如下操作： * 如果是“最终派生类”，初始化vbptr成员变量，

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

19、果是“最终派生类”，调用虚基类的析构函数（按照相反顺序）在VC+中，有虚基类的类的构造函数接受一个隐藏的“最终派生类标志”，标示虚基类是否需要初始化。对于析构函数，VC+采用“分层析构模型”，代码中加入一个隐藏的析构函数，该函数被用于析构包含虚基类的类（对于“最终派生类”实例而言）；代码中再加入另一个析构函数，析构不包含虚基类的类。前一个析构函数调用后一个。5.6.2 虚析构函数与delete操作符考虑结构V和W。struct V virtual V(); struct W : V operator delete();析构函数可以为虚。一个类如果有虚析构函数的话，将会象有其他虚函数一样，拥有一

20、个虚函数表指针，虚函数表中包含一项，其内容为指向对该类适用的虚析构函数的地址。这些机制和普通虚函数相同。虚析构函数的特别之处在于：当类实例被销毁时，虚析构函数被隐含地调用。调用地（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 del

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

22、ete操作符。6 数组堆上分配空间的数组使虚析构函数进一步复杂化。问题变复杂的原因有两个：1、 堆上分配空间的数组，由于数组可大可小，所以，数组大小值应该和数组一起保存。因此，堆上分配空间的数组会分配额外的空间来存储数组元素的个数；2、 当数组被删除时，数组中每个元素都要被正确地释放，即使当数组大小不确定时也必须成功完成该操作。然而，派生类可能比基类占用更多的内存空间，从而使正确释放比较困难。struct WW : W int w1; ;pv = new Wm;delete pv; / delete m Ws (sizeof(W) = sizeof(V)pv = new WWn;delete

23、pv; / delete n WWs (sizeof(WW) sizeof(V)译者注：WW从W继承，增加了一个成员变量，因此，WW占用的内存空间比W大。然而，不管指针pv指向W的数组还是WW的数组，delete都必须正确地释放WW或W对象占用的内存空间。虽然从严格意义上来说，数组delete的多态行为C+标准并未定义，然而，微软有一些客户要求实现该行为。因此，在MSC+中，该行为是用另一个编译器生成的虚析构帮助函数来完成。该函数被称为“向量delete析构函数”（因其针对特定的类定制，比如WW，所以，它能够遍历数组的每个元素，调用对每个元素适用的析构函数）。7 异常处理简单说来，异常处理是C

24、+标准委员会工作文件提供的一种机制，通过该机制，一个函数可以通知其调用者“异常”情况的发生，调用者则能据此选择合适的代码来处理异常。该机制在传统的“函数调用返回，检查错误状态代码”方法之外，给程序提供了另一种处理错误的手段。因为C+是面向对象的语言，很自然地，C+中用对象来表达异常状态。并且，使用何种异常处理也是基于“抛出的”异常对象的静态或动态类型来决定的。不光如此，既然C+总是保证超出范围的对象能够被正确地销毁，异常实现也必须保证当控制从异常抛出点转换到异常“捕获”点时（栈展开），超出范围的对象能够被自动、正确地销毁。考虑如下例子：struct X X(); ; / exception o

25、bject classstruct Z Z(); Z(); ; / class with a destructorextern 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实际抛出异常。这

26、段程序会抛出异常。在main中，加入了处理异常的try & catch框架，当调用f(0)时，f构造z1，调用g(0)后，再构造z2，再调用g(-1)，此时g发现参数为负，抛出X异常对象。我们希望在某个调用层次上，该异常能够得到处理。既然g和f都没有建立处理异常的框架，我们就只能希望main函数建立的异常处理框架能够处理X异常对象。实际上，确实如此。当控制被转移到main中异常捕获点时，从g中的异常抛出点到main中的异常捕获点之间，该范围内的对象都必须被销毁。在本例中，z2和z1应该被销毁。谈到异常处理的具体实现方式，一般情况下，在抛出点和捕获点都使用“表”来表述能够捕获异常对象的类型；并且

27、，实现要保证能够在特定的捕获点真正捕获特定的异常对象；一般地，还要运用抛出的对象来初始化捕获语句的“实参”。通过合理地选择编码方案，可以保证这些表格不会占用过多的内存空间。异常处理的开销到底如何？让我们再考虑一下函数f。看起来f没有做异常处理。f确实没有包含try，catch，或者是throw关键字，因此，我们会猜异常处理应该对f没有什么影响。错！编译器必须保证一旦z1被构造，而后续调用的任何函数向f抛回了异常，异常又出了f的范围时，z1对象能被正确地销毁。同样，一旦z2被构造，编译器也必须保证后续抛出异常时，能够正确地销毁z2和z1。要实现这些“展开”语意，编译器必须在后台提供一种机制，该机

28、制在调用者函数中，针对调用的函数抛出的异常动态决定异常环境（处理点）。这可能包括在每个函数的准备工作和善后工作中增加额外的代码，在最糟糕的情况下，要针对每一套对象初始化的情况更新状态变量。例如，上述例子中，z1应被销毁的异常环境当然与z2和z1都应该被销毁的异常环境不同，因此，不管是在构造z1后，还是继而在构造z2后，VC+都要分别在状态变量中更新（存储）新的值。所有这些表，函数调用的准备和善后工作，状态变量的更新，都会使异常处理功能造成可观的内存空间和运行速度开销。正如我们所见，即使在没有使用异常处理的函数中，该开销也会发生。幸运的是，一些编译器可以提供编译选项，关闭异常处理机制。那些不需要异常处理机制的代码，就可以避免这些额外的开销了。8 小结好了，现在你可以写C+编译器了（开个玩笑）。在本文中，我们讨论了许多重要的C+运行实现问题。我们发现，很多美妙的C+语言特性的开销很低，同时，其他一些美妙的特性（译者注：主要是和“虚”字相关的东西）将造成较大的开销。C+很多实现机制都是在后台默默地为你工作。一般说来，单独看一段代码时，很难衡量这段代码造成的运行时开销，必须把这段代码放到一个更大的环境中来考察，运行时开销问题才能得到比较明确的答案。第 29 页-