Http://Blog.Huang-Wei.Com/2010/08/09/C%E4%B8%AD%E5%AE%9E%E7%8E%B0%E5%A7%94%E6%89%98%EF%BC%88delegate%EF%BC%89/
C++中实现委托（Delegate）
公司的项目里有用到Don Clugston的FastDelegate，当时只知道是类似boost::function的东西，UI上当watcher用的比较多，所以也没去关注。今天想写个事件触发器时，突然想起这茬子，看来有必要认真的研究学习下了。
搜了下网上关于Delegate的东西，有很多网友自个实现的简易版本，CodeProject上有2个开源项目写的不错，一个就是FastDelegate，还有一个模仿C#的Delegate。FastDelegate的实现依赖于编译器，作者NB的研究了各种编译器在各种平台上生成的汇编代码，将C++中神秘的成员函数调用还原普通的函数调用，其调用的汇编代码用他的框架在运行时“生成”，使任何函数都可以无差别的挂接在他的Delegate之上。如MicrosoftVirtualMFP这样的编译后得到的函数结构。
作者原文是英文的，网上已有翻译，我这就贴下，作为笔记。
| 成员函数指针与高性能的C++委托（上篇） |
| 撰文：Don Clugston |
| 引子 标准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*为参数的函数，这个函数返回一个浮点值，声明如下：
应注意，对每一个函数的参数组合，函数指针的类型应该是不同的。在Microsoft Visual C++（以下称MSVC）中，对三种不同的调用方式有不同的类型：__cdecl, __stdcall, 和__fastcall。如果你的函数指针指向一个型如float some_func(int, char *)的函数，这样做就可以了：
你可以将一种类型的函数指针转换成另一种函数指针类型，但你不可以将一个函数指针指向一个void *型的数据指针。其他的转换操作就不用详叙了。一个函数指针可以被设置为0来表明它是一个空指针。所有的比较运算符（==, !=, <, >, <=, >=）都可以使用，可以使用”==0″或通过一个显式的布尔转换来测试指针是否为空（null）。
注意使用了特殊的运算符（::*），而”SomeClass”是声明中的一部分。成员函数指针有一个可怕的限制：它们只能指向一个特定的类 中的成员函数。对每一种参数的组合，需要有不同的成员函数指针类型，而且对每种使用const修饰的函数和不同类中的函数，也要有不同的函数指针类型。在 MSVC中，对下面这四种调用方式都有一种不同的调用类型：__cdecl, __stdcall, __fastcall, 和 __thiscall。（__thiscall是缺省的方式，有趣的是，在任何官方文档中从没有对__thiscall关键字的详细描述，但是它经常在错 误信息中出现。如果你显式地使用它，你会看到”它被保留作为以后使用（it is reserved for future use）”的错误提示。）如果你使用了成员函数指针，你最好使用typedef以防止混淆。
不要怪我使用如此奇怪的语法——看起来C++的设计者对标点符号有着由衷的感情！C++相对于C增加了三种特殊运算符来支持成员指 针。”::*”用于指针的声明，而”->*”和”.*”用来调用指针指向的函数。这样看起来对一个语言模糊而又很少使用的部分的过分关注是多余 的。（你当然可以重载”->*”这些运算符，但这不是本文所要涉及的范围。）
奇怪的是，&DerivedClass::some_member_func是一个SomeClass类的成员函数指针，而不是 DerivedClass类的成员函数指针！（一些编译器稍微有些不同：比如，对于Digital Mars C++，在上面的例子中，&DerivedClass::some_member_func会被认为没有定义。）但是，如果在 DerivedClass类中重写（override）了some_member_func函数，代码就无法通过编译，因为现在 的&DerivedClass::some_member_func已成为DerivedClass类中的成员函数指针！
对于情况(a)，static_cast<Base1mfp>(x)是合法的，而 static_cast<Base2mfp>(x)则是错误的。然而情况(b)却与之相反。你只可以安全地将子类的成员函数指针转化为第一个 基类的成员函数指针！如果你要实验一下，MSVC会发出C4407号警告，而Digital Mars C++会出现编译错误。如果用reinterpret_cast代替static_cast，这两个编译器都会发生错误，但是两种编译器对此有着不同的原 因。但是一些编译器对此细节置之不理，大家可要小心了！ 用来做例子给C++初学者看，帮助它们学习语法；或者
注意到编译器必须生成汇编代码来调用成员函数指针，其实编译器对SomeClass类一无所知。显然，除非链接器进行了一些极端精细的优化 措施，否则代码会忽视类的实际定义而能够正确地运行。而这造成的直接后果是，你可以”安全地”调用从完全不同的其他类中转换过来的成员函数指针。 成员函数指针与高性能的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个类定义如下：
假如我们建立了 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运算符计算所获得的数据：
看 着表中的数据，你是不是觉得很惊奇？你可以清楚地看到编写一段在一些环境中可以运行而在另一些编译器中不能运行的代码是很容易的。不同的编译器之间，它们 的内部实现显然是有很大差别的；事实上，我认为编译器在实现语言的其他特性上并没有这样明显的差别。对实现的细节进行研究你会发现一些奇怪的问题。 一般，编译器采取最差的，而且一直使用最普通的形式。比如对于下面这个结构：
对于几乎所有的编译器， delta和 vindex用来调整传递给函数的 this指针，比如 Borland的计算方法是：
（其中，“ *”是提取该地址中的数值， 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后结果为奇数。它们的计算方法是： |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||