標準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)

typedef void (Derived::* Derived_mfp)();

typedef void (Derived2::* Derived2_mfp)();

typedef void (Base1::* Base1mfp) ();

typedef void (Base2::* Base2mfp) ();

Derived_mfp x;

對于情況(a)，static_cast<Base1mfp>(x)是合法的，而static_cast<Base2mfp>(x)則是錯誤的。然而情況(b)卻與之相反。你只可以安全地將子類的成員函數指針轉化為第一個基類的成員函數指針！如果你要實驗一下，MSVC會發出C4407號警告，而Digital Mars C++會出現編譯錯誤。如果用reinterpret_cast代替static_cast，這兩個編譯器都會發生錯誤，但是兩種編譯器對此有著不同的原因。但是一些編譯器對此細節置之不理，大家可要小心了！

標準C++中另一條有趣的規則是：你可以在類定義之前聲明它的成員函數指針。這對一些編譯器會有一些無法預料的副作用。我待會討論這個問題，現在你只要知道要盡可能得避免這種情況就是了。

需要值得注意的是，就像成員函數指針，標準C++中同樣提供了成員數據指針（member data pointer）。它們具有相同的操作符，而且有一些實現原則也是相同的。它們用在stl::stable_sort的一些實現方案中，而對此很多其他的應用我就不再提及了。

成員函數指針的使用

現在你可能會覺得成員函數指針是有些奇異。但它可以用來做什么呢？對此我在網上做了非常廣泛的調查。最后我總結出使用成員函數指針的兩點原因：

?

用來做例子給C++初學者看，幫助它們學習語法；或者

為了實現"委托（delegate）"！

成員函數指針在STL和Boost庫的單行函數適配器（one-line function adaptor）中的使用是微不足道的，而且允許你將成員函數和標準算法混合使用。但是它們最重要的應用是在不同類型的應用程序框架中，比如它們形成了MFC消息系統的核心。

當你使用MFC的消息映射宏（比如ON_COMMAND）時，你會組裝一個包含消息ID和成員函數指針（型如：CCmdTarget::*成員函數指針）的序列。這是MFC類必須繼承CCmdTarget才可以處理消息的原因之一。但是，各種不同的消息處理函數具有不同的參數列表（比如OnDraw處理函數的第一個參數的類型為CDC *），所以序列中必須包含各種不同類型的成員函數指針。MFC是怎樣做到這一點的呢？MFC利用了一個可怕的編譯器漏洞（hack），它將所有可能出現的成員函數指針放到一個龐大的聯合（union）中，從而避免了通常需要進行的C++類型匹配檢查。（看一下afximpl.h和cmdtarg.cpp中名為MessageMapFunctions的union，你就會發現這一恐怖的事實。）因為MFC有如此重要的一部分代碼，所以事實是，所有的編譯器都為這個漏洞開了綠燈。（但是，在后面我們會看到，如果一些類用到了多重繼承，這個漏洞在MSVC中就不會起作用，這正是在使用MFC時只能必須使用單一繼承的原因。）

在boost::function中有類似的漏洞（但不是太嚴重）。看起來如果你想做任何有關成員函數指針的比較有趣的事，你就必須做好與這個語言的漏洞進行挑戰的準備。要是你想否定C++的成員函數指針設計有缺陷的觀點，看來是很難的。

在寫這篇文章中，我有一點需要指明："允許成員函數指針之間進行轉換（cast），而不允許在轉換完成后調用其中的函數"，把這個規則納入C++的標準中是可笑的。首先，很多流行的編譯器對這種轉換不支持（所以，轉換是標準要求的，但不是可移植的）。其次，所有的編譯器，如果轉換成功，調用轉換后的成員函數指針時仍然可以實現你預期的功能：那編譯器就沒有所謂的"undefined behavior（未定義的行為）"這類錯誤出現的必要了（調用（Invocation）是可行的，但這不是標準！）。第三，允許轉換而不允許調用是完全沒有用處的，只有轉換和調用都可行，才能方便而有效地實現委托，從而使這種語言受益。

為了讓你確信這一具有爭議的論斷，考慮一下在一個文件中只有下面的一段代碼，這段代碼是合法的：

class SomeClass;

typedef void (SomeClass::* SomeClassFunction)(void);

void Invoke(SomeClass *pClass, SomeClassFunction funcptr) {

(pClass->*funcptr)(); };

注意到編譯器必須生成匯編代碼來調用成員函數指針，其實編譯器對SomeClass類一無所知。顯然，除非鏈接器進行了一些極端精細的優化措施，否則代碼會忽視類的實際定義而能夠正確地運行。而這造成的直接后果是，你可以"安全地"調用從完全不同的其他類中轉換過來的成員函數指針。

為解釋我的斷言的另一半——轉換并不能按照標準所說的方式進行，我需要在細節上討論編譯器是怎樣實現成員函數指針的。我同時會解釋為什么使用成員函數指針的規則具有如此嚴格的限制。獲得詳細論述成員函數指針的文檔不是太容易，并且大家對錯誤的言論已經習以為常了，所以，我仔細檢查了一系列編譯器生成的匯編代碼......