成员函数指针与高性能的C++委托（中篇）

Member Function Pointers and the Fastest Possible C++ Delegates

撰文： Don Clugston

翻译：周翔

（接上篇）

成员函数指针——为什么那么复杂？

类的成员函数和标准的 C函数有一些不同。与被显式声明的参数相似，类的成员函数有一个隐藏的参数 this ，它指向一个类的实例。根据不同的编译器， this 或者被看作内部的一个正常的参数，或者会被特别对待（比如，在 VC++中， this一般通过 ECX寄存器来传递，而普通的成员函数的参数被直接压在堆栈中）。t his 作为参数和其他普通的参数有着本质的不同，即使一个成员函数受一个普通函数的支配，在标准 C++中也没有理由使这个成员函数和其他的普通函数（ ordinary function）的行为相同，因为没有 thiscall 关键字来保证它使用像普通参数一样正常的调用规则。成员函数是一回事，普通函数是另外一回事（ Member functions are from Mars, ordinary functions are from Venus）。

你可能会猜测，一个成员函数指针和一个普通函数指针一样，只是一个代码指针。然而这种猜测也许是错误的。在大多数编译器中，一个成员函数指针要比一个普通的函数指针要大许多。更奇怪的是，在 Visual C++中，一个成员函数指针可以是 4、 8、 12甚至 16个字节长，这取决于它所相关的类的性质，同时也取决于编译器使用了怎样的编译设置！成员函数指针比你想象中的要复杂得多，但也不总是这样。

让我们回到二十世纪 80年代初期，那时，最古老的 C++编译器 CFront刚刚开发完成，那时C++语言只能实现单一继承，而且成员函数指针刚被引入，它们很简单：它们就像普通的函数指针，只是附加了额外的 this 作为它们的第一个参数，你可以将一个成员函数指针转化成一个普通的函数指针，并使你能够对这个额外添加的参数产生足够的重视。

这个田园般的世界随着 CFront 2.0的问世被击得粉碎。它引入了模版和多重继承，多重继承所带来的破坏造成了成员函数指针的改变。问题在于，随着多重继承，调用之前你不知道使用哪一个父类的 this 指针，比如，你有 4个类定义如下：

class A {

public:

virtual int Afunc() { return 2; };

};

class B {

public:

int Bfunc() { return 3; };

};

// C是个单一继承类，它只继承于 A

class C: public A {

public:

int Cfunc() { return 4; };

};

// D 类使用了多重继承

class D: public A, public B {

public:

int Dfunc() { return 5; };

};

假如我们建立了 C类的一个成员函数指针。在这个例子中， Afunc和 Cfunc都是 C的成员函数，所以我们的成员函数指针可以指向 Afunc或者 Cfunc。但是 Afunc需要一个 this指针指向C::A(后面我叫它 Athis )，而 Cfunc需要一个 this指针指向 C（后面我叫它 Cthis ）。编译器的设计者们为了处理这种情况使用了一个把戏（ trick）：他们保证了 A类在物理上保存在 C类的头部（即 C类的起始地址也就是一个 A类的一个实例的起始地址），这意味着 Athis == Cthis。我们只需担心一个 this指针就够了，并且对于目前这种情况，所有的问题处理得还可以。

现在，假如我们建立一个 D类的成员函数指针。在这种情况下，我们的成员函数指针可以指向Afunc、 Bfunc或 Dfunc。但是 Afunc需要一个 this指针指向 D::A，而 Bfunc需要一个 this指针指向 D::B。这时，这个把戏就不管用了，我们不可以把 A类和 B类都放在 D类的头部。所以，D类的一个成员函数指针不仅要说明要指明调用的是哪一个函数，还要指明使用哪一个 this指针。编译器知道 A类占用的空间有多大，所以它可以对 Athis增加一个 delta = sizeof(A)偏移量就可以将 Athis指针转换为 Bthis指针。

如果你使用虚拟继承（ virtual inheritance），比如虚基类，情况会变得更糟，你可以不必为搞懂这是为什么太伤脑筋。就举个例子来说吧，编译器使用虚拟函数表 （ virtual function table——“ vtable”）来保存每一个虚函数、函数的地址和 virtual_delta： 将当前的 this指针转换为实际函数需要的 this指针时所要增加的位移量。

综上所述，为了支持一般形式的成员函数指针，你需要至少三条信息：函数的地址，需要增加到 this指针上的 delta位移量，和一个虚拟函数表中的索引。对于 MSVC来说，你需要第四条信息：虚拟函数表（ vtable）的地址。

成员函数指针的实现

那么，编译器是怎样实现成员函数指针的呢？这里是对不同的 32、 64和 16位的编译器，对各种不同的数据类型（有 int、 void*数据指针、代码指针（比如指向静态函数的指针）、在单一（ single-）继承、多重（ multiple-）继承、虚拟（ virtual-）继承和未知类型（ unknown）的继承下的类的成员函数指针）使用 sizeof运算符计算所获得的数据：

编译器

选项

int

DataPtr

CodePtr

Single

Multi

Virtual

Unknown

MSVC

 

4

4

4

4

8

12

16

MSVC

/vmg

4

4

4

16#

16#

16#

16

MSVC

/vmg /vmm

4

4

4

8#

8#

--

8#

Intel_IA32

 

4

4

4

4

8

12

12

Intel_IA32

/vmg /vmm

4

4

4

4

8

--

8

Intel_Itanium

 

4

8

8

8

12

20

20

G++

 

4

4

4

8

8

8

8

Comeau

 

4

4

4

8

8

8

8

DMC

 

4

4

4

4

4

4

4

BCC32

 

4

4

4

12

12

12

12

BCC32

/Vmd

4

4

4

4

8

12

12

WCL386

 

4

4

4

12

12

12

12

CodeWarrior

 

4

4

4

12

12

12

12

XLC

 

4

8

8

20

20

20

20

DMC

small

2

2

2

2

2

2

2

DMC

medium

2

2

4

4

4

4

4

WCL

small

2

2

2

6

6

6

6

WCL

compact

2

4

2

6

6

6

6

WCL

medium

2

2

4

8

8

8

8

WCL

large

2

4

4

8

8

8

8

注：

# 表示使用 __single/__multi/__virtual_inheritance关键字的时候代表 4、 8或 12 。

这些编译器是 Microsoft Visual C++ 4.0 to 7.1 (.NET 2003), GNU G++ 3.2 (MingW binaries, http://www.mingw.org/), Borland BCB 5.1 (http://www.borland.com/), Open Watcom (WCL) 1.2 (http://www.openwatcom.org/), Digital Mars (DMC) 8.38n (http://www.digitalmars.com/), Intel C++ 8.0 for Windows IA-32, Intel C++ 8.0 for Itanium, (http://www.intel.com/), IBM XLC for AIX (Power, PowerPC), Metrowerks Code Warrior 9.1 for Windows (http://www.metrowerks.com/), 和 Comeau C++ 4.3 (http://www.comeaucomputing.com/). Comeau的数据是在它支持的 32位平台（ x86, Alpha, SPARC等）上得出的。 16位的编译器的数据在四种 DOS配置（ tiny, compact, medium, 和 large）下测试得出，用来显示各种不同代码和数据指针的大小。 MSVC在 /vmg的选项下进行了测试，用来显示“成员指针的全部特性”。（如果你拥有在列表中没有出现的编译器，请告知我。非 x86处理机下的编译器测试结果有独特的价值。）

　

看 着表中的数据，你是不是觉得很惊奇？你可以清楚地看到编写一段在一些环境中可以运行而在另一些编译器中不能运行的代码是很容易的。不同的编译器之间，它们 的内部实现显然是有很大差别的；事实上，我认为编译器在实现语言的其他特性上并没有这样明显的差别。对实现的细节进行研究你会发现一些奇怪的问题。

一般，编译器采取最差的，而且一直使用最普通的形式。比如对于下面这个结构：

// Borland (缺省设置 ) 和 Watcom C++.

struct {

FunctionPointer m_func_address;

int m_delta;

int m_vtable_index; //如果不是虚拟继承，这个值为 0 。

} ;

// Metrowerks CodeWarrior使用了稍微有些不同的方式。

//即使在不允许多重继承的 Embedded C++的模式下，它也使用这样的结构！

struct {

int m_delta;

int m_vtable_index; // 如果不是虚拟继承，这个值为 -1。

FunctionPointer m_func_address;

};

// 一个早期的 SunCC版本显然使用了另一种规则：

struct {

int m_vtable_index; //如果是一个非虚拟函数（ non-virtual function），这个值为0。

FunctionPointer m_func_address; //如果是一个虚拟函数（ virtual function），这个值为 0。

int m_delta;

};

//下面是微软的编译器在未知继承类型的情况下或者使用 /vmg选项时使用的方法：

struct {

FunctionPointer m_func_address;

int m_delta;

int m_vtordisp;

int m_vtable_index; // 如果不是虚拟继承，这个值为 0

} ;

// AIX (PowerPC)上 IBM的 XLC编译器：

struct {

FunctionPointer m_func_address; // 对 PowerPC来说是 64位

int m_vtable_index;

int m_delta;

int m_vtordisp;

};

// GNU g++使用了一个机灵的方法来进行空间优化

struct {

union {

FunctionPointer m_func_address; // 其值总是 4的倍数

int m_vtable_index_2; // 其值被 2除的结果总是奇数

};

int m_delta;

};

对于几乎所有的编译器， delta和 vindex用来调整传递给函数的 this指针，比如 Borland的计算方法是：

adjustedthis = *(this + vindex -1) + delta // 如果 vindex!=0

adjustedthis = this + delta // 如果 vindex=0

（其中，“ *”是提取该地址中的数值， adjustedthis是调整后的 this指针——译者注）

Borland使用了一个优化方法：如果这个类是单一继承的，编译器就会知道delta和vindex的值是0，所以它就可以跳过上面的计算方法。

GNU编译器使用了一个奇怪的优化方法。可以清楚地看到，对于多重继承来说，你必须查看vtable（虚拟函数表）以获得 voffset（虚拟函数偏移地址）来计算 this指针。当你做这些事情的时候，你可能也把函数指针保存在 vtable中。通过这些工作，编译器将 m_func_address和m_vtable_index合二为一（即放在一个 union中），编译器区别这两个变量的方法是使函数指针（ m_func_address）的值除以 2后结果为偶数，而虚拟函数表索引 (m_vtable_index_2)除以 2后结果为奇数。它们的计算方法是：

adjustedthis = this + delta

if (funcadr & 1) //如果是奇数

call (* ( *delta + (vindex+1)/2) + 4)

else //如果是偶数

call funcadr

（其中， funcadr 是函数地址除以 2得出的结果。——译者注）

Inter的 Itanium编译器（但不是它们的 x86编译器）对虚拟继承（ virtual inheritance）的情况也使用了 unknown_inheritance结构，所以，一个虚拟继承的指针有 20字节大小，而不是想象中的 16字节。

// Itanium， unknown 和 virtual inheritance下的情况 .

struct {

FunctionPointer m_func_address; //对 Itanium来说是 64位

int m_delta;

int m_vtable_index;

int m_vtordisp;

};

我不能保证 Comeau C++使用的是和 GNU相同的技术，也不能保证它们是否使用 short代替int使这种虚拟函数指针的结构的大小缩小至 8个字节。最近发布的 Comeau C++版本为了兼容微软的编译器也使用了微软的编译器关键字（我想它也只是忽略这些关键字而不对它们进行实质的相关处理罢了）。

Digital Mars编译器（即最初的 Zortech C++到后来的 Symantec C++）使用了一种不同的优化方法。对单一继承类来说，一个成员函数指针仅仅是这个函数的地址。但涉及到更复杂的继承时，这个成员函数指针指向一个形式转换函数（ thunk function） ，这个函数可以实现对this指 针的必要调整并可用来调用实际的成员函数。每当涉及到多重继承的时候，每一个成员函数的指针都会有这样一个形式转换函数，这对函数调用来说是非常有效的。 但是这意味着，当使用多重继承的时候，子类的成员函数指针向基类成员函数指针的转换就会不起作用了。可见，这种编译器对编译代码的要求比其他的编译器要严 格得多。

很多嵌入式系统的编译器不允许多重继承。这样，这些编译器就避免了可能出现的问题：一个成员函数指针就是一个带有隐藏 this指针参数的普通函数指针。

微软 "smallest for class"方法的问题

微软的编译器使用了和 Borland相似的优化方法。它们都使单一继承的情况具有最优的效率。但不像 Borland，微软在缺省条件下成员函数指针省略了值为 0 的指针入口（ entry），我称这种技术为“ smallest for class”方法：对单一继承类来说，一个成员函数指针仅保存了函数的地址（ m_func_address），所以它有 4字节长。而对于多重继承类来说，由于用到了偏移地址（m_delta），所以它有 8字节长。对虚拟继承，会用到 12个字节。这种方法确实节省空间，但也有其它的问题。

首先，将一个成员函数指针在子类和基类之间进行转化会改变指针的大小！因此，信息是会丢失的。其次，当一个成员函数指针在它的类定义之前声明的时候，编译器必须算出要分配给这个指针多少空间，但是这样做是不安全的，因为在定义之前编译器不可能知道这个类的继承方式。对 Intel C++和早期的微软编译器来说，编译器仅仅对指针的大小进行猜测，一旦在源文件中猜测错误，你的程序会在运行时莫名其妙地崩溃。所以，微软的编译器中增加了一些保留字： __single_inheritance, __multiple_inheritance,和 __virtual_inheritance，并增设了一些编译器开关（ compiler switch），如 /vmg，让所有的成员函数指针有相同的大小，而对原本个头小的成员函数指针的空余部分用 0填充。 Borland编译器也增加了一些编译器开关，但没有增加新的关键字。 Intel的编译器可以识别 Microsoft增加的那些关键字，但它在能够找到类的定义的情况下会对这些关键字不做处理。

对于 MSVC来说，编译器需要知道类的 vtable在哪儿；通常就会有一个 this指针的偏移量（vtordisp），这个值对所有这个类中的成员函数来说是不变的，但对每个类来说会是不同的。对于 MSVC，经调整过的 this指针是在原 this指针的基础上经过下面的计算得出的：

if (vindex=0) //如果不是虚拟继承（ _virtual_inheritance）

adjustedthis = this + delta

else //如果是

adjustedthis = this + delta + vtordisp + *(*(this + vtordisp) + vindex)

在虚拟继承的情况下， vtordisp的值并不保存在 __virtual_inheritance指针中，而是在发现函数调用的代码时，编译器才将其相应的汇编代码“嵌”进去。但是对于未知类型的继承，编译器需要尽可能地通过读代码确定它的继承类型，所以，编译器将虚拟继承指针（ virtual inheritance pointer）分为两类（ __virtual_inheritance和 __unknown_inheritance）。

理论上，所有的编译器设计者应该在 MFP（成员函数指针）的实现上有所变革和突破。但在实际上，这是行不通的，因为这使现在编写的大量代码都需要改变。微软曾发表了一篇非常古老的文章（ http://msdn.microsoft.com/archive/en-us/dnarvc/html/jangrayhood.asp）来解释Visual C++运作的实现细节。这篇文章是 Jan Gray写的，他曾在 1990年设计了 Microsoft C++的对象模型。尽管这篇文章发表于 1994年，但这篇文章仍然很重要——这意味着 C++的对象模型在长达 15年的时间里（ 1990年到 2004年）没有丝毫改变。

现在，我想你对成员函数指针的事情已经知道得太多了。要点是什么？我已为你建立了一个规则。虽然各种编译器的在这方面的实现方法有很大的不同，但是也有一些有用的共同点：不管对哪种形式的类，调用一个成员函数指针生成的汇编语言代码是完全相同的。有一种特例是使用了“ smallest for class”技术的非标准的编译器，即使是这种情况，差别也是很微小的。这个事实可以让我们继续探索怎样去建立高性能的委托（ delegate）。