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

委托（delegate） 和成员函数指针不同，你不难发现委托的用处。最重要的，使用委托可以很容易地实现一个Subject/Observer设计模式的改进版[GoF, p. 293]。Observer（观察者）模式显然在GUI中有很多的应用，但我发现它对应用程序核心的设计也有很大的作用。委托也可用来实现策略（Strategy）[GoF, p. 315]和状态（State）[GoF, p. 305]模式。 现在，我来说明一个事实，委托和成员函数指针相比并不仅仅是好用，而且比成员函数指针简单得多！既然所有的.NET语言都实现了委托，你可能会猜想如此高层的概念在汇编代码中并不好实现。但事实并不是这样：委托的实现确实是一个底层的概念，而且就像普通的函数调用一样简单（并且很高效）。一个C++委托只需要包含一个this指针和一个简单的函数指针就够了。当你建立一个委托时，你提供这个委托一个this指针，并向它指明需要调用哪一个函数。编译器可以在建立委托时计算出调整this指针需要的偏移量。这样在使用委托的时候，编译器就什么事情都不用做了。这一点更好的是，编译器可以在编译时就可以完成全部这些工作，这样的话，委托的处理对编译器来说可以说是微不足道的工作了。在x86系统下将委托处理成的汇编代码就应该是这么简单： mov ecx, [this] call [pfunc] 但是，在标准C++中却不能生成如此高效的代码。 Borland为了解决委托的问题在它的C++编译器中加入了一个新的关键字（__closure）,用来通过简洁的语法生成优化的代码。GNU编译器也对语言进行了扩展，但和Borland的编译器不兼容。如果你使用了这两种语言扩展中的一种，你就会限制自己只使用一个厂家的编译器。而如果你仍然遵循标准C++的规则，你仍然可以实现委托，但实现的委托就不会是那么高效了。 有趣的是，在C#和其他.NET语言中，执行一个委托的时间要比一个函数调用慢8倍（参见/library/en-us/dndotnet/html/fastmanagedcode.asp）。我猜测这可能是垃圾收集和.NET安全检查的需要。最近，微软将“统一事件模型（unified event model）”加入到Visual C++中，随着这个模型的加入，增加了__event、 __raise、__hook、__unhook、event_source和event_receiver等一些关键字。坦白地说，我对加入的这些特性很反感，因为这是完全不符合标准的，这些语法是丑陋的，因为它们使这种C++不像C++，并且会生成一堆执行效率极低的代码。 解决这个问题的推动力：对高效委托（fast delegate）的迫切需求 使用标准C++实现委托有一个过度臃肿的症状。大多数的实现方法使用的是同一种思路。这些方法的基本观点是将成员函数指针看成委托#0;#0;但这样的指针只能被一个单独的类使用。为了避免这种局限，你需要间接地使用另一种思路：你可以使用模版为每一个类建立一个“成员函数调用器（member function invoker）”。委托包含了this指针和一个指向调用器（invoker）的指针，并且需要在堆上为成员函数调用器分配空间。 对于这种方案已经有很多种实现，包括在CodeProject上的实现方案。各种实现在复杂性上、语法（比如，有的和C#的语法很接近）上、一般性上有所不同。最具权威的一个实现是boost::function。最近，它已经被采用作为下一个发布的C++标准版本中的一部分[Sutter1]。希望它能够被广泛地使用。 就像传统的委托实现方法一样，我同样发觉这种方法并不十分另人满意。虽然它提供了大家所期望的功能，但是会混淆一个潜在的问题：人们缺乏对一个语言的底层的构造。 “成员函数调用器”的代码对几乎所有的类都是一样的，在所有平台上都出现这种情况是令人沮丧的。毕竟，堆被用上了。但在一些应用场合下，这种新的方法仍然无法被接受。 我做的一个项目是离散事件模拟器，它的核心是一个事件调度程序，用来调用被模拟的对象的成员函数。大多数成员函数非常简单：它们只改变对象的内部状态，有时在事件队列（event queue）中添加将来要发生的事件，在这种情况下最适合使用委托。但是，每一个委托只被调用（invoked）一次。一开始，我使用了boost::function，但我发现程序运行时，给委托所分配的内存空间占用了整个程序空间的三分之一还要多！“我要真正的委托！”我在内心呼喊着，“真正的委托只需要仅仅两行汇编指令啊！” 我并不能总是能够得到我想要的，但后来我很幸运。我在这儿展示的代码（代码下载链接见译者注）几乎在所有编译环境中都产生了优化的汇编代码。最重要的是，调用一个含有单个目标的委托（single-