引子標(biāo)準(zhǔn)C++中沒有真正的面向?qū)ο蟮暮瘮?shù)指針。這一點對C++來說是不幸的，因為面向?qū)ο蟮闹羔槪ㄒ步凶?#8220;閉包（closure）”或“委托（delegate）”）在一些語言中已經(jīng)證明了它寶貴的價值。在Delphi (Object Pascal)中，面向?qū)ο蟮暮瘮?shù)指針是Borland可視化組建庫（VCL，Visual Component Library）的基礎(chǔ)。而在目前，C#使“委托”的概念日趨流行，這也正顯示出C#這種語言的成功。在很多應(yīng)用程序中，“委托”簡化了松耦合對象的設(shè)計模式[GoF]。這種特性無疑在標(biāo)準(zhǔn)C++中也會產(chǎn)生很大的作用。
很遺憾，C++中沒有“委托”，它只提供了成員函數(shù)指針（member function pointers）。很多程序員從沒有用過函數(shù)指針，這是有特定的原因的。因為函數(shù)指針自身有很多奇怪的語法規(guī)則（比如“->*”和“.*”操作符），而且很難找到它們的準(zhǔn)確含義，并且你會找到更好的辦法以避免使用函數(shù)指針。更具有諷刺意味的是：事實上，編譯器的編寫者如果實現(xiàn)“委托”的話會比他費勁地實現(xiàn)成員函數(shù)指針要容易地多！
在這篇文章中，我要揭開成員函數(shù)指針那“神秘的蓋子”。在扼要地重述成員函數(shù)指針的語法和特性之后，我會向讀者解釋成員函數(shù)指針在一些常用的編譯器中是怎樣實現(xiàn)的，然后我會向大家展示編譯器怎樣有效地實現(xiàn)“委托”。最后我會利用這些精深的知識向你展示在C++編譯器上實現(xiàn)優(yōu)化而可靠的“委托”的技術(shù)。比如，在Visual C++(6.0, .NET, and .NET 2003)中對單一目標(biāo)委托（single-target delegate）的調(diào)用，編譯器僅僅生成兩行匯編代碼！
函數(shù)指針
下面我們復(fù)習(xí)一下函數(shù)指針。在C和C++語言中，一個命名為my_func_ptr的函數(shù)指針指向一個以一個int和一個char*為參數(shù)的函數(shù)，這個函數(shù)返回一個浮點值，聲明如下：
float (*my_func_ptr)(int, char *);
//為了便于理解，我強烈推薦你使用typedef關(guān)鍵字。
//如果不這樣的話，當(dāng)函數(shù)指針作為一個函數(shù)的參數(shù)傳遞的時候，
// 程序會變得晦澀難懂。
// 這樣的話，聲明應(yīng)如下所示：
typedef float (*MyFuncPtrType)(int, char *);
MyFuncPtrType my_func_ptr;
應(yīng)注意，對每一個函數(shù)的參數(shù)組合，函數(shù)指針的類型應(yīng)該是不同的。在Microsoft Visual C++（以下稱MSVC）中，對三種不同的調(diào)用方式有不同的類型：__cdecl, __stdcall, 和__fastcall。如果你的函數(shù)指針指向一個型如float some_func(int, char *)的函數(shù)，這樣做就可以了：
my_func_ptr = some_func;
//當(dāng)你想調(diào)用它所指向的函數(shù)時，你可以這樣寫：
(*my_func_ptr)(7, "Arbitrary String");
你可以將一種類型的函數(shù)指針轉(zhuǎn)換成另一種函數(shù)指針類型，但你不可以將一個函數(shù)指針指向一個void *型的數(shù)據(jù)指針。其他的轉(zhuǎn)換操作就不用詳敘了。一個函數(shù)指針可以被設(shè)置為0來表明它是一個空指針。所有的比較運算符（==, !=, <, >, <=, >=）都可以使用，可以使用“==0”或通過一個顯式的布爾轉(zhuǎn)換來測試指針是否為空（null）。
在C語言中，函數(shù)指針通常用來像qsort一樣將函數(shù)作為參數(shù)，或者作為Windows系統(tǒng)函數(shù)的回調(diào)函數(shù)等等。函數(shù)指針還有很多其他的應(yīng)用。函數(shù)指針的實現(xiàn)很簡單：它們只是“代碼指針（code pointer）”，它們體現(xiàn)在匯編語言中是用來保存子程序代碼的首地址。而這種函數(shù)指針的存在只是為了保證使用了正確的調(diào)用規(guī)范。
成員函數(shù)指針
在C++程序中，很多函數(shù)是成員函數(shù)，即這些函數(shù)是某個類中的一部分。你不可以像一個普通的函數(shù)指針那樣指向一個成員函數(shù)，正確的做法應(yīng)該是，你必須使用一個成員函數(shù)指針。一個成員函數(shù)的指針指向類中的一個成員函數(shù)，并和以前有相同的參數(shù)，聲明如下：
float (SomeClass::*my_memfunc_ptr)(int, char *);
//對于使用const關(guān)鍵字修飾的成員函數(shù)，聲明如下：
float (SomeClass::*my_const_memfunc_ptr)(int, char *) const;
注意使用了特殊的運算符（::*），而“SomeClass”是聲明中的一部分。成員函數(shù)指針有一個可怕的限制：它們只能指向一個特定的類中的成員函數(shù)。對每一種參數(shù)的組合，需要有不同的成員函數(shù)指針類型，而且對每種使用const修飾的函數(shù)和不同類中的函數(shù)，也要有不同的函數(shù)指針類型。在MSVC中，對下面這四種調(diào)用方式都有一種不同的調(diào)用類型：__cdecl, __stdcall, __fastcall, 和 __thiscall。（__thiscall是缺省的方式，有趣的是，在任何官方文檔中從沒有對__thiscall關(guān)鍵字的詳細描述，但是它經(jīng)常在錯誤信息中出現(xiàn)。如果你顯式地使用它，你會看到“它被保留作為以后使用（it is reserved for future use）”的錯誤提示。）如果你使用了成員函數(shù)指針，你最好使用typedef以防止混淆。
將函數(shù)指針指向型如float SomeClass::some_member_func(int, char *)的函數(shù)，你可以這樣寫：
my_memfunc_ptr = &SomeClass::some_member_func;
很多編譯器（比如MSVC）會讓你去掉“&”，而其他一些編譯器（比如GNU G++）則需要添加“&”，所以在手寫程序的時候我建議把它添上。若要調(diào)用成員函數(shù)指針，你需要先建立SomeClass的一個實例，并使用特殊操作符“->*”，這個操作符的優(yōu)先級較低，你需要將其適當(dāng)?shù)胤湃雸A括號內(nèi)。
SomeClass *x = new SomeClass;
(x->*my_memfunc_ptr)(6, "Another Arbitrary Parameter");
//如果類在棧上，你也可以使用“.*”運算符。
SomeClass y;
(y.*my_memfunc_ptr)(15, "Different parameters this time");
不要怪我使用如此奇怪的語法——看起來C++的設(shè)計者對標(biāo)點符號有著由衷的感情！C++相對于C增加了三種特殊運算符來支持成員指針。“::*”用于指針的聲明，而“->*”和“.*”用來調(diào)用指針指向的函數(shù)。這樣看起來對一個語言模糊而又很少使用的部分的過分關(guān)注是多余的。（你當(dāng)然可以重載“->*”這些運算符，但這不是本文所要涉及的范圍。）
一個成員函數(shù)指針可以被設(shè)置成0，并可以使用“==”和“!=”比較運算符，但只能限定在同一個類中的成員函數(shù)的指針之間進行這樣的比較。任何成員函數(shù)指針都可以和0做比較以判斷它是否為空。與函數(shù)指針不同，不等運算符（<, >, <=, >=）對成員函數(shù)指針是不可用的。
成員函數(shù)指針的怪異之處
成員函數(shù)指針有時表現(xiàn)得很奇怪。首先，你不可以用一個成員函數(shù)指針指向一個靜態(tài)成員函數(shù)，你必須使用普通的函數(shù)指針才行（在這里“成員函數(shù)指針”會產(chǎn)生誤解，它實際上應(yīng)該是“非靜態(tài)成員函數(shù)指針”才對）。其次，當(dāng)使用類的繼承時，會出現(xiàn)一些比較奇怪的情況。比如，下面的代碼在MSVC下會編譯成功（注意代碼注釋）：
＃i nclude “stdio.h”
class SomeClass {
public:
virtual void some_member_func(int x, char *p) {
printf("In SomeClass"); };
};
class DerivedClass : public SomeClass {
public:
// 如果你把下一行的注釋銷掉，帶有 line (*)的那一行會出現(xiàn)錯誤
// virtual void some_member_func(int x, char *p) { printf("In DerivedClass"); };
};
int main() {
//聲明SomeClass的成員函數(shù)指針
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類的成員函數(shù)指針，而不是DerivedClass類的成員函數(shù)指針！（一些編譯器稍微有些不同：比如，對于Digital Mars C++，在上面的例子中，&DerivedClass::some_member_func會被認(rèn)為沒有定義。）但是，如果在DerivedClass類中重寫（override）了some_member_func函數(shù)，代碼就無法通過編譯，因為現(xiàn)在的&DerivedClass::some_member_func已成為DerivedClass類中的成員函數(shù)指針！
成員函數(shù)指針之間的類型轉(zhuǎn)換是一個討論起來非常模糊的話題。在C++的標(biāo)準(zhǔn)化的過程中，在涉及繼承的類的成員函數(shù)指針時，對于將成員函數(shù)指針轉(zhuǎn)化為基類的成員函數(shù)指針還是轉(zhuǎn)化為子類成員函數(shù)指針的問題和是否可以將一個類的成員函數(shù)指針轉(zhuǎn)化為另一個不相關(guān)的類的成員函數(shù)指針的問題，人們曾有過很激烈的爭論。然而不幸的是，在標(biāo)準(zhǔn)委員會做出決定之前，不同的編譯器生產(chǎn)商已經(jīng)根據(jù)自己對這些問題的不同的回答實現(xiàn)了自己的編譯器。根據(jù)標(biāo)準(zhǔn)（第5.2.10/9節(jié)），你可以使用reinterpret_cast在一個成員函數(shù)指針中保存一個與本來的類不相關(guān)的類的成員函數(shù)。有關(guān)成員函數(shù)指針轉(zhuǎn)換的問題的最終結(jié)果也沒有確定下來。你現(xiàn)在所能做的還是像以前那樣——將成員函數(shù)指針轉(zhuǎn)化為本類的成員函數(shù)的指針。在文章的后面我會繼續(xù)討論這個問題，因為這正是各個編譯器對這樣一個標(biāo)準(zhǔn)沒有達成共識的一個話題。
在一些編譯器中，在基類和子類的成員函數(shù)指針之間的轉(zhuǎn)換時常有怪事發(fā)生。當(dāng)涉及到多重繼承時，使用reinterpret_cast將子類轉(zhuǎn)換成基類時，對某一特定編譯器來說有可能通過編譯，而也有可能通不過編譯，這取決于在子類的基類列表中的基類的順序！下面就是一個例子：
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)卻與之相反。你只可以安全地將子類的成員函數(shù)指針轉(zhuǎn)化為第一個基類的成員函數(shù)指針！如果你要實驗一下，MSVC會發(fā)出C4407號警告，而Digital Mars C++會出現(xiàn)編譯錯誤。如果用reinterpret_cast代替static_cast，這兩個編譯器都會發(fā)生錯誤，但是兩種編譯器對此有著不同的原因。但是一些編譯器對此細節(jié)置之不理，大家可要小心了！
標(biāo)準(zhǔn)C++中另一條有趣的規(guī)則是：你可以在類定義之前聲明它的成員函數(shù)指針。這對一些編譯器會有一些無法預(yù)料的副作用。我待會討論這個問題，現(xiàn)在你只要知道要盡可能得避免這種情況就是了。
需要值得注意的是，就像成員函數(shù)指針，標(biāo)準(zhǔn)C++中同樣提供了成員數(shù)據(jù)指針（member data pointer）。它們具有相同的操作符，而且有一些實現(xiàn)原則也是相同的。它們用在stl::stable_sort的一些實現(xiàn)方案中，而對此很多其他的應(yīng)用我就不再提及了。
成員函數(shù)指針的使用
現(xiàn)在你可能會覺得成員函數(shù)指針是有些奇異。但它可以用來做什么呢？對此我在網(wǎng)上做了非常廣泛的調(diào)查。最后我總結(jié)出使用成員函數(shù)指針的兩點原因：
* 用來做例子給
* C++初學(xué)者看，幫助它們學(xué)習(xí)語法；或者 為了實現(xiàn)“委托（
delegate）”！
成員函數(shù)指針在STL和Boost庫的單行函數(shù)適配器（one-line function adaptor）中的使用是微不足道的，而且允許你將成員函數(shù)和標(biāo)準(zhǔn)算法混合使用。但是它們最重要的應(yīng)用是在不同類型的應(yīng)用程序框架中，比如它們形成了MFC消息系統(tǒng)的核心。
當(dāng)你使用MFC的消息映射宏（比如ON_COMMAND）時，你會組裝一個包含消息ID和成員函數(shù)指針（型如：CCmdTarget::*成員函數(shù)指針）的序列。這是MFC類必須繼承CCmdTarget才可以處理消息的原因之一。但是，各種不同的消息處理函數(shù)具有不同的參數(shù)列表（比如OnDraw處理函數(shù)的第一個參數(shù)的類型為CDC *），所以序列中必須包含各種不同類型的成員函數(shù)指針。MFC是怎樣做到這一點的呢？MFC利用了一個可怕的編譯器漏洞（hack），它將所有可能出現(xiàn)的成員函數(shù)指針放到一個龐大的聯(lián)合（union）中，從而避免了通常需要進行的C++類型匹配檢查。（看一下afximpl.h和cmdtarg.cpp中名為MessageMapFunctions的union，你就會發(fā)現(xiàn)這一恐怖的事實。）因為MFC有如此重要的一部分代碼，所以事實是，所有的編譯器都為這個漏洞開了綠燈。（但是，在后面我們會看到，如果一些類用到了多重繼承，這個漏洞在MSVC中就不會起作用，這正是在使用MFC時只能必須使用單一繼承的原因。）
在boost::function中有類似的漏洞（但不是太嚴(yán)重）。看起來如果你想做任何有關(guān)成員函數(shù)指針的比較有趣的事，你就必須做好與這個語言的漏洞進行挑戰(zhàn)的準(zhǔn)備。要是你想否定C++的成員函數(shù)指針設(shè)計有缺陷的觀點，看來是很難的。
在寫這篇文章中，我有一點需要指明：“允許成員函數(shù)指針之間進行轉(zhuǎn)換（cast），而不允許在轉(zhuǎn)換完成后調(diào)用其中的函數(shù)”，把這個規(guī)則納入C++的標(biāo)準(zhǔn)中是可笑的。首先，很多流行的編譯器對這種轉(zhuǎn)換不支持（所以，轉(zhuǎn)換是標(biāo)準(zhǔn)要求的，但不是可移植的）。其次，所有的編譯器，如果轉(zhuǎn)換成功，調(diào)用轉(zhuǎn)換后的成員函數(shù)指針時仍然可以實現(xiàn)你預(yù)期的功能：那編譯器就沒有所謂的“undefined behavior（未定義的行為）”這類錯誤出現(xiàn)的必要了（調(diào)用（Invocation）是可行的，但這不是標(biāo)準(zhǔn)！）。第三，允許轉(zhuǎn)換而不允許調(diào)用是完全沒有用處的，只有轉(zhuǎn)換和調(diào)用都可行，才能方便而有效地實現(xiàn)委托，從而使這種語言受益。
為了讓你確信這一具有爭議的論斷，考慮一下在一個文件中只有下面的一段代碼，這段代碼是合法的：
class SomeClass;
typedef void (SomeClass::* SomeClassFunction)(void);
void Invoke(SomeClass *pClass, SomeClassFunction funcptr)
{
(pClass->*funcptr)();
};
注意到編譯器必須生成匯編代碼來調(diào)用成員函數(shù)指針，其實編譯器對SomeClass類一無所知。顯然，除非鏈接器進行了一些極端精細的優(yōu)化措施，否則代碼會忽視類的實際定義而能夠正確地運行。而這造成的直接后果是，你可以“安全地”調(diào)用從完全不同的其他類中轉(zhuǎn)換過來的成員函數(shù)指針。
為解釋我的斷言的另一半——轉(zhuǎn) 換并不能按照標(biāo)準(zhǔn)所說的方式進行，我需要在細節(jié)上討論編譯器是怎樣實現(xiàn)成員函數(shù)指針的。我同時會解釋為什么使用成員函數(shù)指針的規(guī)則具有如此嚴(yán)格的限制。獲 得詳細論述成員函數(shù)指針的文檔不是太容易，并且大家對錯誤的言論已經(jīng)習(xí)以為常了，所以，我仔細檢查了一系列編譯器生成的匯編代碼……