成員函數指針——為什麼那麼複雜？

引子

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

　　typ

成員函數指針——為什麼那麼複雜？

　　類的成員函數和标準的C函數有一些不同。與被顯式聲明的參數相似，類的成員函數有一個隐藏的參數this，它指向一個類的執行個體。根據不同的編譯器，this或者被看作内部的一個正常的參數，或者會被特别對待（比如，在VC++中，this一般通過ECX寄存器來傳遞，而普通的成員函數的參數被直接壓在堆棧中）。this作為參數和其他普通的參數有着本質的不同，即使一個成員函數受一個普通函數的支配，在标準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個類定義如下：

　　class A {

　　public:

　　virtual int Afunc() { return 2; };

　　};

　　class B {

　　public:

　　int Bfunc() { return 3; };

　　};

　　// C是個單一繼承類，它隻繼承于A

　　class C: public A {

　　public:

　　int Cfunc() { return 4; };

　　};

　　// D 類使用了多重繼承

　　class D: public A, public B {

　　public:

　　int Dfunc() { return 5; };

　　};

　　假如我們建立了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運算符計算所獲得的資料：

　　    

　　注：

　　　　# 表示使用__single/__multi/__virtual_inheritance關鍵字的時候代表4、8或12。

　　　　這些編譯器是Microsoft Visual C++ 4.0 to 7.1 (.NET 2003), GNU G++ 3.2 (MingW binaries, http://www.mingw.org/), Borland BCB 5.1 (http://www.borland.com/), Open Watcom (WCL) 1.2 (http://www.openwatcom.org/), Digital Mars (DMC) 8.38n (http://www.digitalmars.com/), Intel C++ 8.0 for Windows IA-32, Intel C++ 8.0 for Itanium, (http://www.intel.com/), IBM XLC for AIX (Power, PowerPC), Metrowerks Code Warrior 9.1 for Windows (http://www.metrowerks.com/), 和 Comeau C++ 4.3 (http://www.comeaucomputing.com/). Comeau的資料是在它支援的32位平台（x86, Alpha, SPARC等）上得出的。16位的編譯器的資料在四種DOS配置（tiny, compact, medium, 和 large）下測試得出，用來顯示各種不同代碼和資料指針的大小。MSVC在/vmg的選項下進行了測試，用來顯示“成員指針的全部特性”。（如果你擁有在清單中沒有出現的編譯器，請告知我。非x86處理機下的編譯器測試結果有獨特的價值。）

　　看着表中的資料，你是不是覺得很驚奇？你可以清楚地看到編寫一段在一些環境中可以運作而在另一些編譯器中不能運作的代碼是很容易的。不同的編譯器之間，它們的内部實作顯然是有很大差别的；事實上，我認為編譯器在實作語言的其他特性上并沒有這樣明顯的差别。對實作的細節進行研究你會發現一些奇怪的問題。

　　一般，編譯器采取最差的，而且一直使用最普通的形式。比如對于下面這個結構：

　　// Borland (預設設定) 和Watcom C++.

　　struct {

　　FunctionPointer m_func_address;

　　int m_delta;

　　int m_vtable_index; //如果不是虛拟繼承，這個值為0。

　　};

　　// Metrowerks CodeWarrior使用了稍微有些不同的方式。

　　//即使在不允許多重繼承的Embedded C++的模式下，它也使用這樣的結構！

　　struct {

　　int m_delta;

　　int m_vtable_index; // 如果不是虛拟繼承，這個值為-1。

　　FunctionPointer m_func_address;

　　};

　　// 一個早期的SunCC版本顯然使用了另一種規則：

　　struct {

　　int m_vtable_index; //如果是一個非虛拟函數（non-virtual function），這個值為0。

　　FunctionPointer m_func_address; //如果是一個虛拟函數（virtual function），這個值為0。

　　int m_delta;

　　};

　　//下面是微軟的編譯器在未知繼承類型的情況下或者使用/vmg選項時使用的方法：

　　struct {

　　FunctionPointer m_func_address;

　　int m_delta;

　　int m_vtordisp;

　　int m_vtable_index; // 如果不是虛拟繼承，這個值為

};　　

　　// AIX (PowerPC)上IBM的XLC編譯器：

　　　　struct {

　　　　FunctionPointer m_func_address; // 對PowerPC來說是64位

　　　　int m_vtable_index;

　　　　int m_delta;

　　　　int m_vtordisp;

　　　　};

　　// GNU g++使用了一個機靈的方法來進行空間優化　　

　　struct {　　

　　union {　　

　　FunctionPointer m_func_address; // 其值總是4的倍數

　　　　int m_vtable_index_2; // 其值被2除的結果總是奇數

　　　　};　　

　　int m_delta;　　　　

};

　　　　對于幾乎所有的編譯器delta和vindex用來調整傳遞給函數的this指針，比如Borland的計算方法是：

　　　　adjustedthis = *(this + vindex -1) + delta // 如果vindex!=0

　　　　adjustedthis = this + delta // 如果vindex=0

　　　　（其中，“*”是提取該位址中的數值，adjustedthis是調整後的this指針——譯者注）

　　　　Borland使用了一個優化方法：如果這個類是單一繼承的，編譯器就會知道delta和vindex的值是0，是以它就可以跳過上面的計算方法。

　　　　GNU編譯器使用了一個奇怪的優化方法。可以清楚地看到，對于多重繼承來說，你必須檢視vtable（虛拟函數表）以獲得voffset（虛拟函數偏移位址）來計算this指針。當你做這些事情的時候，你可能也把函數指針儲存在vtable中。