`
weiyinchao88
  • 浏览: 1176187 次
文章分类
社区版块
存档分类
最新评论

C++对象布局及多态实现的探索(四)

 
阅读更多
构造函数中的虚成员函数调用

  在构造函数中调用虚成员函数,虽然这是个不很常用的技术,但研究一下可以加深对虚函数机制及对象构造过程的理解。这个问题也和一般直观上的认识有所差异。先看看下面的两个类定义。
struct C180
{
C180() {
foo();
this->foo();
}
virtual foo() {
cout << "<< C180.foo this: " << this << " vtadr: " << *(void**)this << endl;
}
};
struct C190 : public C180
{
C190() {}
virtual foo() {
cout << "<< C190.foo this: " << this << " vtadr: " << *(void**)this << endl;
}
};
  父类中有一个虚函数,并且父类在它的构造函数中调用了这个虚函数,调用时它采用了两种方法一种是直接调用,一种是通过this指针调用。同时子类又重写了这个虚函数。
  我们可以来预测一下如果构造一个C190的对象会发生什么情况。
  我们知道,在构造一个对象时,首先会按对象的大小得到一块内存(在heap上或在stack上),然后会把指向这块内存的指针做为this指针来调用类的构造函数,对这块内存进行初始化。如果对象有父类就会先调用父类的构造函数(并依次递归),如果有多个父类(多重继承)会依次对父类的构造函数进行调用,并会适当的调整this指针的位置。在调用完所有的父类的构造函数后,再执行自己的代码。
  照上面的分析构造C190时也会调用C180的构造函数,这时在C180构造函数中的第一个foo调用为静态绑定,会调用到C180::foo()函数。第二个foo调用是通过指针调用的,这时多态行为会发生,应该调用的是C190::foo()函数。
  执行如下代码:
C190 obj;
obj.foo();
  结果为:
<< C180.foo this: 0012F7A4 vtadr: 0045C404
<< C180.foo this: 0012F7A4 vtadr: 0045C404
<< C190.foo this: 0012F7A4 vtadr: 0045C400
  和我们的分析大相径庭。前2行是构造C190时的输出,后1行是我们用静态绑定方式调用的C190::foo()函数。第2行的输出说明多态行为并没有象预期的那样发生。而且比较输出的最后一列,发现在调用C180的构造函数时对象对应的虚表和构造后对象对应的虚表不是同一个。其实这正是奥秘的所在。
  为此我查了一下C++标准规范。在12.7.3条中有明确的规定。这是一种特例,在这种情况下,即在构造子类时调用父类的构造函数,而父类的构造函数中又调用了虚成员函数,这个虚成员函数即使被子类重写,也不允许发生多态的行为。即,这时必须要调用父类的虚函数,而不子类重写后的虚函数。
  我想这样做的原因是因为在调用父类的构造函数时,对象中属于子类部分的成员变量是肯定还没有初始化的,因为子类构造函数中的代码还没有被执行。如果这时允许多态的行为,即通过父类的构造函数调用到了子类的虚函数,而这个虚函数要访问属于子类的数据成员时就有可能出错。
  我们看看VC7.1生成的汇编代码就可以很容易的理解这个行为了。
  这是C190的构造函数:
01 00426FE0 push ebp
02 00426FE1 mov ebp,esp
03 00426FE3 sub esp,0CCh
04 00426FE9 push ebx
05 00426FEA push esi
06 00426FEB push edi
07 00426FEC push ecx
08 00426FED lea edi,[ebp+FFFFFF34h]
09 00426FF3 mov ecx,33h
10 00426FF8 mov eax,0CCCCCCCCh
11 00426FFD rep stos dword ptr [edi]
12 00426FFF pop ecx
13 00427000 mov dword ptr [ebp-8],ecx
14 00427003 mov ecx,dword ptr [ebp-8]
15 00427006 call 0041D451
16 0042700B mov eax,dword ptr [ebp-8]
17 0042700E mov dword ptr [eax],45C400h
18 00427014 mov eax,dword ptr [ebp-8]
19 00427017 pop edi
20 00427018 pop esi
21 00427019 pop ebx
22 0042701A add esp,0CCh
23 00427020 cmp ebp,esp
24 00427022 call 0041DDF2
25 00427027 mov esp,ebp
26 00427029 pop ebp
27 0042702A ret
  开始部分的指令在前面几篇中陆续解释过,这里不再详述。我们看看第15是对父类的构造函数C180::C180()的调用,根据前文的说明,我们知道此时ecx中放的是this指针,也就是C190对象的地址。这时如果跳到this指针批向的地址看看会发现值为0xcccccccc即没有初始化,虚表指针也没有被初始化。那么我们跟着跳到C180的构造函数看看。
01 00427040 push ebp
02 00427041 mov ebp,esp
03 00427043 sub esp,0CCh
04 00427049 push ebx
05 0042704A push esi
06 0042704B push edi
07 0042704C push ecx
08 0042704D lea edi,[ebp+FFFFFF34h]
09 00427053 mov ecx,33h
10 00427058 mov eax,0CCCCCCCCh
11 0042705D rep stos dword ptr [edi]
12 0042705F pop ecx
13 00427060 mov dword ptr [ebp-8],ecx
14 00427063 mov eax,dword ptr [ebp-8]
15 00427066 mov dword ptr [eax],45C404h
16 0042706C mov ecx,dword ptr [ebp-8]
17 0042706F call 0041DA8C
18 00427074 mov ecx,dword ptr [ebp-8]
19 00427077 call 0041DA8C
20 0042707C mov eax,dword ptr [ebp-8]
21 0042707F pop edi
22 00427080 pop esi
23 00427081 pop ebx
24 00427082 add esp,0CCh
25 00427088 cmp ebp,esp
26 0042708A call 0041DDF2
27 0042708F mov esp,ebp
28 00427091 pop ebp
29 00427092 ret
  看看第15行,在this指针的位置也就是对象的起始处,填入了一个4字节的值0x0045C404,其实这就是我们前面的打印过的C180的虚表地址。第16、17行和18、19行分别调用了两次foo()函数,用的都是静态绑定。这个就有点奇怪,因为对后一个调用我们使用了this指针,照理应该是动态绑定才对。可这里却是静态绑定,为什么编译器要做这个优化?我们继承往后看。
  这个函数执行完后,我们再回到C190构造函数中,我们接着看C190构造函数汇编代码的第17行,这里又在对象的起始处重新填入了0x0045C400,覆盖了原来的值,而这个值就是我们前面打印过的真正的C190的虚表地址。
  也就是说VC7.1是通过在调用构造函数的真正代码前把对象的虚指针值设置为指向对应类的虚表来实现C++规范的相应语义。C++标准中只规定了行为,并不规定具体编译器在实现这一行为时所用的方法。象我们上面看到的,即使是通过this指针调用,编译器也把它优化为静态绑定,也就是说即使不做这个虚指针的调整也不会有错。之所以要调整我想可能是防止在被调用的虚成员中又通过this指针来调用其他的虚函数,不过谁会这么变态呢?
  还有值得一提的是,VC7.1中有一个扩展属性可以用来抑制编译器产生对虚指针进行调整的代码。我们可以在C180类的声明中加入这个属性。
struct __declspec(novtable) C180
{
C180() {
foo();
this->foo();
}
virtual foo() {
cout << "<< C180.foo this: " << this << " vtadr: " << *(void**)this << endl;
}
};
  这样再执行前面的代码,输出就会变成:
<< C180.foo this: 0012F7A4 vtadr: CCCCCCCC
<< C180.foo this: 0012F7A4 vtadr: CCCCCCCC
<< C190.foo this: 0012F7A4 vtadr: 0045C400
  由于编译器抑制了对虚指针的调整所以在调C180的构造函数时虚指针的值没有初始化,这时我们才看到多亏编译器把第二个通过this指针对foo的调用优化成了静态绑定,否则由于虚指针没有初始化一定会出现一个指针异常的错误,这就回答我们上面的那个问题。
  在这种情况下产生的汇编代码我就不列了,有兴趣的朋友可以自己去看一看。另外对于析构函数的调用,也请有兴趣的朋友自行分析一下。

  另外这个属性在ATL的代码中大量的使用。在ATL中接口一般为纯虚基类,如果不用这个优化属性,由于在子类即实现类的构造函数中要调用父类的构造函数,而编译器产生的父类构造函数又要设置虚指针的值。所以编译器必须要把父类的虚表构建出来。而实际上这个虚表是没有任何意义的,因为ATL的纯虚接口类的虚函数都是无实现的。这样不仅仅是多了几行无用的设值指令,同时也浪费了空间。有兴趣的朋友可以自行验证一下。

  对这个问题的兴趣源于张水松在工作中和我探讨的一个问题,在此也谢谢他。

 普通的虚继承

  下面我们来看虚继承。首先看看这C020类,它从C010虚继承:
struct C010
{
C010() : c_(0x01) {}
void foo() { c_ = 0x02; }
char c_;
};
struct C020 : public virtual C010
{
C020() : c_(0x02) {}
char c_;
};
  运行如下代码,查看对象的内存布局:
PRINT_SIZE_DETAIL(C020)
  结果为:
The size of C020 is 6
The detail of C020 is c0 c2 45 00 02 01
  很明显对象的起始处是一个指针,然后是子类的成员变量,接下来是父类的成员变量。和以前的讨论不同的是由于使用了虚继承,父类的成员变量被放到了最后面。
  运行如下的代码:
C020 c020;
c020.C010::c_ = 0x04;
  由于子类中的变量和父类中的变量重名,所以我们必须用这种方式来访问属于父类的成员变量,普通情况下不需要这种写法。我们看看后面这行代码对应的汇编代码:
0042387E mov eax,dword ptr [ebp+FFFFF82Ch]
00423884 mov ecx,dword ptr [eax+4]
00423887 mov byte ptr [ebp+ecx+FFFFF82Ch],4
  前面说过对象的起始是一个指针,第1行指令取到这个指针的值,第2行把这个指针指向的地址后移4字节后的值(做为一个4字节的值)取出来。执行完这句我们看看ecx寄存器,可知取出来的值为5。最后一行是真正的赋值指令,它通过在对象的起始处(即[ebp+FFFFF32Ch])加上ecx中的值做偏移值(即5)来得到赋值的目的地址。接合前面的对象布局输出,我们可以发现从对象起始地址开始加5字节的偏移值,刚好得到父类的成员变量的地址。这样我们可以大致分析出直接虚继承的子类的对象布局。
|子类5            |父类1    |
|偏移值指针4,5|子类成员变量1|父类成员变量1|
  (注:第一个数字为所在区域的长度(字节数),偏移值指针后的第二个数字为该指针指向的偏移值。后同。)
  通过查看内存可以发现偏移值指针指向的内存前4字节为0,我不知道它的具体的用途是什么。接下来的4字节是一个32位的整数,也就是真正的偏移值。即从子类的起始位置到被虚继承的父类的起始位置的偏移值,在我们前面的例子中这个值为5(一个指针加一个char成员变量)。
  通过这个分析我们可以看到在虚承继的情况下,通过子类的对象访问父类的普通成员变量的效率是相当低的。如果必须用到虚继承,也应该尽量不要在父类中放置普通成员变量(静态成员变量不受影响)。
  另外为什么微软不把偏移值直接放到子类中,而是采用偏移值指针。我想是因为采用指针的方式更为灵活,即使以后需要扩展也不影响类对象的布局。

  按下来我们再看看这几行代码:
PRINT_OBJ_ADR(c020);
C010 * pt = &c020;
PRINT_PT(pt);
pt->c_ = 0x03;
  第2行声明了一个父类指针,并让它指向一个子类的对象。第3行打印出这个指针的值。运行结果为:
c020's address is : 0012F708
pt's value is : 0012F70D
  我们可以看到赋值后的指针的值并不等于赋给它的对象地址值。也就是说在这个赋值过程中编译器进行了额外的工作,即调整了指针的值。我们看看第2行对应的汇编代码,看看编译器究竟做了些什么?
01 004238EA lea eax,[ebp+FFFFF82Ch]
02 004238F0 test eax,eax
03 004238F2 jne 00423900
04 004238F4 mov dword ptr [ebp+FFFFF014h],0
05 004238FE jmp 00423916
06 00423900 mov ecx,dword ptr [ebp+FFFFF82Ch]
07 00423906 mov edx,dword ptr [ecx+4]
08 00423909 lea eax,[ebp+edx+FFFFF82Ch]
09 00423910 mov dword ptr [ebp+FFFFF014h],eax
10 00423916 mov ecx,dword ptr [ebp+FFFFF014h]
11 0042391C mov dword ptr [ebp+FFFFF820h],ecx
  喔!比想象的要复杂的多。一行简单的指针赋值语句却产生了这么多的汇编代码。这行代码本身的语义是取对象的地址赋给一个指针,对于编译器来说它把这做为指针到指针的赋值来处理。由于牵涉到了向上的类型转换,同时又有虚继承存在。根据前面的布局分析,在虚继承的情况下,父类位于对象布局的后部。因此在这里要做一个指针位置的调整。由于调整要根据源指针来进行计算,所以先要对源指针的合法性进行检查,以避免运行时的指针异常错误。前3行的汇编指令就是在做这件事,检查源指针是否为NULL。如果为NULL则执行4、5、10、11行,最终给pt赋0。如果不为NULL跳至第6行执行到最后。重要的是第6、7、8行代码,它们通过偏移值指针找到偏移值,并以此来调整指针的位置,让目的指针最终指向对象中的父类部分的数据成员。
  对比一下普通的指针赋值,我们可以对上面赋值的复杂性和低效有更深的认识。
C010 * pt1 = NULL;
C010 * pt2 = pt1;
  这两行相应的汇编代码为:
0042397D mov dword ptr [ebp+FFFFF814h],0
00423987 mov eax,dword ptr [ebp+FFFFF814h]
0042398D mov dword ptr [ebp+FFFFF808h],eax
  第1行是普通的赋值,编译器并不做任何的检查,即使源指针为NULL。因为它不需要根据源指针(本处为NULL)做任何计算。第2个赋值也很直接,只是通过eax做了一个中转。这里我们就可以看到前面的虚继承下的子类指针到父类指针的赋值是我么的低效。在程序中应尽量的避免这种代码。

  (未完待继)

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics