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