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

引子
　　标准C++中没有真正的面向对象的函数指针。这一点对C++来说是不幸的，因为面向对象的指针（也叫做“闭包（closure）”或“委托（delegate）”）在一些语言中已经证明了它宝贵的价值。在Delphi (Object Pascal)中，面向对象的函数指针是Borland可视化组建库（VCL，Visual Component Library）的基础。而在目前，C#使“委托”的概念日趋流行，这也正显示出C#这种语言的成功。在很多应用程序中，“委托”简化了松耦合对象的设计模式[GoF]。这种特性无疑在标准C++中也会产生很大的作用。
　　很遗憾，C++中没有“委托”，它只提供了成员函数指针（member function pointers）。很多程序员从没有用过函数指针，这是有特定的原因的。因为函数指针自身有很多奇怪的语法规则（比如“->*”和“.*”操作符），而且很难找到它们的准确含义，并且你会找到更好的办法以避免使用函数指针。更具有讽刺意味的是：事实上，编译器的编写者如果实现“委托”的话会比他费劲地实现成员函数指针要容易地多！
　　在这篇文章中，我要揭开成员函数指针那“神秘的盖子”。在扼要地重述成员函数指针的语法和特性之后，我会向读者解释成员函数指针在一些常用的编译器中是怎样实现的，然后我会向大家展示编译器怎样有效地实现“委托”。最后我会利用这些精深的知识向你展示在C++编译器上实现优化而可靠的“委托”的技术。比如，在Visual C++(6.0, .NET, and .NET 2003)中对单一目标委托（single-target delegate）的调用，编译器仅仅生成两行汇编代码！
函数指针
　　下面我们复习一下函数指针。在C和C++语言中，一个命名为my_func_ptr的函数指针指向一个以一个int和一个char*为参数的函数，这个函数返回一个浮点值，声明如下：float (*my_func_ptr)(int, char *);
　　//为了便于理解，我强烈推荐你使用typedef关键字。
　　//如果不这样的话，当函数指针作为一个函数的参数传递的时候，
　　// 程序会变得晦涩难懂。
　　// 这样的话，声明应如下所示：
　　typedef float (*MyFuncPtrType)(int, char *);
　　MyFuncPtrType my_func_ptr;
　　应注意，对每一个函数的参数组合，函数指针的类型应该是不同的。在Microsoft Visual C++（以下称MSVC）中，对三种不同的调用方式有不同的类型：__cdecl, __stdcall, 和__fastcall。如果你的函数指针指向一个型如float some_func(int, char *)的函数，这样做就可以了：
　　my_func_ptr = some_func;
　　当你想调用它所指向的函数时，你可以这样写：
　　(*my_func_ptr)(7, "Arbitrary String");
　　你可以将一种类型的函数指针转换成另一种函数指针类型，但你不可以将一个函数指针指向一个void *型的数据指针。其他的转换操作就不用详叙了。一个函数指针可以被设置为0来表明它是一个空指针。所有的比较运算符（==, !=, <, >, <=, >=）都可以使用，可以使用“==0”或通过一个显式的布尔转换来测试指针是否为空（null）。
　　在C语言中，函数指针通常用来像qsort一样将函数作为参数，或者作为Windows系统函数的回调函数等等。函数指针还有很多其他的应用。函数指针的实现很简单：它们只是“代码指针（code pointer）”，它们体现在汇编语言中是用来保存子程序代码的首地址。而这种函数指针的存在只是为了保证使用了正确的调用规范。
成员函数指针
　　在C++程序中，很多函数是成员函数，即这些函数是某个类中的一部分。你不可以像一个普通的函数指针那样指向一个成员函数，正确的做法应该是，你必须使用一个成员函数指针。个成员函数的指针指向类中的一个成员函数，并和以前有相同的参数，声明如下：
　　float (SomeClass::*my_memfunc_ptr)(int, char *);
　　//对于使用const关键字修饰的成员函数，声明如下：
　　float (SomeClass::*my_const_memfunc_ptr)(int, char *) const;
　　注意使用了特殊的运算符（::*），而“SomeClass”是声明中的一部分。成员函数指针有一个可怕的限制：它们只能指向一个特定的类中的成员函数。对每一种参数的组合，需要有不同的成员函数指针类型，而且对每种使用const修饰的函数和不同类中的函数，也要有不同的函数指针类型。在MSVC中，对下面这四种调用方式都有一种不同的调用类型：__cdecl, __stdcall, __fastcall, 和 __thiscall。（__thiscall是缺省的方式，有趣的是，在任何官方文档中从没有对__thiscall关键字的详细描述，但是它经常在错误信息中出现。如果你显式地使用它，你会看到“它被保留作为以后使用（it is reserved for future use）”的错误提示。）如果你使用了成员函数指针，你最好使用typedef以防止混淆。
　　将函数指针指向型如float SomeClass::some_member_func(int, char *)的函数，你可以这样写：
　　my_memfunc_ptr = &SomeClass::some_member_func;
　　很多编译器（比如MSVC）会让你去掉“&”，而其他一些编译器（比如GNU G++）则需要添加“&”，所以在手写程序的时候我建议把它添上。若要调用成员函数指针，你需要先建立SomeClass的一个实例，并使用特殊操作符“->*”，这个操作符的优先级较低，你需要将其适当地放入圆括号内。
　　SomeClass *x = new SomeClass;
　　(x->*my_memfunc_ptr)(6, "Another Arbitrary Parameter");
　　//如果类在栈上，你也可以使用“.*”运算符。
　　SomeClass y;
　　(y.*my_memfunc_ptr)(15, "Different parameters this time");
　　不要怪我使用如此奇怪的语法——看起来C++的设计者对标点符号有着由衷的感情！C++相对于C增加了三种特殊运算符来支持成员指针。“::*”用于指针的声明，而“->*”和“.*”用来调用指针指向的函数。这样看起来对一个语言模糊而又很少使用的部分的过分关注是多余的。（你当然可以重载“->*”这些运算符，但这不是本文所要涉及的范围。）
　　一个成员函数指针可以被设置成0，并可以使用“==”和“!=”比较运算符，但只能限定在同一个类中的成员函数的指针之间进行这样的比较。任何成员函数指针都可以和0做比较以判断它是否为空。与函数指针不同，不等运算符（<, >, <=, >=）对成员函数指针是不可用的。
成员函数指针的怪异之处
　　成员函数指针有时表现得很奇怪。首先，你不可以用一个成员函数指针指向一个静态成员函数，你必须使用普通的函数指针才行（在这里“成员函数指针”会产生误解，它实际上应该是“非静态成员函数指针”才对）。其次，当使用类的继承时，会出现一些比较奇怪的情况。比如，下面的代码在MSVC下会编译成功（注意代码注释）：
　　#include “stdio.h”
　　class SomeClass {
　　public:
　　virtual void some_member_func(int x, char *p) {
　　printf("In SomeClass"); };
　　};
　　class DerivedClass : public SomeClass {
　　public:
　　// 如果你把下一行的注释销掉，带有 line (*)的那一行会出现错误
　　// virtual void some_member_func(int x, char *p) { printf("In DerivedClass"); };
　　};
　　int main() {
　　//声明SomeClass的成员函数指针
　　typedef void (SomeClass::*SomeClassMFP)(int, char *);
　　SomeClassMFP my_memfunc_ptr;
　　my_memfunc_ptr = &DerivedClass::some_member_func; // ---- line (*)
　　return 0;
　　}
　　奇怪的是，&DerivedClass::some_member_func是一个SomeClass类的成员函数指针，而不是DerivedClass类的成员函数指针！（一些编译器稍微有些不同：比如，对于Digital Mars C++，在上面的例子中，&DerivedClass::some_member_func会被认为没有定义。）但是，如果在DerivedClass类中重写（override）了some_member_func函数，代码就无法通过编译，因为现在的&DerivedClass::some_member_func已成为DerivedClass类中的成员函数指针！
　　成员函数指针之间的类型转换是一个讨论起来非常模糊的话题。在C++的标准化的过程中，在涉及继承的类的成员函数指针时，对于将成员函数指针转化为基类的成员函数指针还是转化为子类成员函数指针的问题和是否可以将一个类的成员函数指针转化为另一个不相关的类的成员函数指针的问题，人们曾有过很激烈的争论。然而不幸的是，在标准委员会做出决定之前，不同的编译器生产商已经根据自己对这些问题的不同的回答实现了自己的编译器。根据标准（第5.2.10/9节），你可以使用reinterpret_cast在一个成员函数指针中保存一个与本来的类不相关的类的成员函数。有关成员函数指针转换的问题的最终结果也没有确定下来。你现在所能做的还是像以前那样——将成员函数指针转化为本类的成员函数的指针。在文章的后面我会继续讨论这个问题，因为这正是各个编译器对这样一个标准没有达成共识的一个话题。
　　在一些编译器中，在基类和子类的成员函数指针之间的转换时常有怪事发生。当涉及到多重继承时，使用reinterpret_cast将子类转换成基类时，对某一特定编译器来说有可能通过编译，而也有可能通不过编译，这取决于在子类的基类列表中的基类的顺序！下面就是一个例子：
　　class Derived: public Base1, public Base2 // 情况 (a)
　　class Derived2: public Base2, public Base1 // 情况 (b)
　　typ
成员函数指针——为什么那么复杂？
　　类的成员函数和标准的C函数有一些不同。与被显式声明的参数相似，类的成员函数有一个隐藏的参数this，它指向一个类的实例。根据不同的编译器，this或者被看作内部的一个正常的参数，或者会被特别对待（比如，在VC++中，this一般通过ECX寄存器来传递，而普通的成员函数的参数被直接压在堆栈中）。this作为参数和其他普通的参数有着本质的不同，即使一个成员函数受一个普通函数的支配，在标准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运算符计算所获得的数据：
　　    

　　注：
　　　　# 表示使用__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; // 如果不是虚拟继承，这个值为
};　　
　　// 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中。