原作者:劉未鵬
2003年9月發(fā)表于《程序員》,本文較之有極大改動(dòng)，特別在中后部分:-)
前奏
如你所知，Boost庫(kù)是個(gè)特性完備，且具備工業(yè)強(qiáng)度的庫(kù)，眾多C++權(quán)威的參與使其達(dá)到了登峰造極的程度。尤其泛型的強(qiáng)大威力在其中被發(fā)揮得淋漓盡致，令人瞠目結(jié)舌。 然而弱水三千，我們只取一瓢飲。下面，我試圖從最單純的世界開(kāi)始，一步一步帶領(lǐng)你進(jìn)入源碼的世界，去探究boost::function(下文簡(jiǎn)稱function)內(nèi)部的精微結(jié)構(gòu)。通常 ，在單純的情況下，對(duì)函數(shù)的調(diào)用簡(jiǎn)單而且直觀，像這樣：
1: int fun(int someVal);
2: int main(){ 3: fun(10);
4: }
然而你可能需要在某個(gè)時(shí)刻將函數(shù)指針保存下來(lái)，并在以后的另一個(gè)時(shí)刻調(diào)用它，像這樣：
1: int fun(int);
2: typedef int (*func_handle)(int);
3: int main()
4: { 5: func_handle fh=fun;
6: ... //do something
7: fh(10);
8: }
但是，如果fun形式為void fun(int)呢？如你所見(jiàn)，fun可能有無(wú)數(shù)種形式，如果對(duì)fun的每一個(gè)形式都typedef一個(gè)對(duì)應(yīng)的func_handle，則程序員會(huì)焦頭爛額，不勝其擾，代碼也可能變得臃腫和丑陋不堪，甚至如果fun是仿函數(shù)呢？ 幸運(yùn)的是C++泛型可以使代碼變得優(yōu)雅精致，面對(duì)無(wú)數(shù)種的可能，泛型是最好的選擇。 因此，你只是需要一個(gè)能夠保存函數(shù)指針的泛型模板類(對(duì)應(yīng)于Command模式)，因?yàn)榉盒途幊逃幸粋€(gè)先天性的優(yōu)勢(shì)——可以借助編譯器的力量在編譯期根據(jù)用戶提供的型別信息化身千萬(wàn)(具現(xiàn)化)，所以一個(gè)泛型的類可以有無(wú)限個(gè)具現(xiàn)體，也就是說(shuō)可以保存無(wú)限多種可能型別的函數(shù)或類似函數(shù)的東西(如，仿函數(shù))。這個(gè)類(在Boost庫(kù)中的類名為function)與函數(shù)指針相比應(yīng)該有以下一些優(yōu)勢(shì)：
- 同一個(gè)function對(duì)象應(yīng)能夠接受與它形式兼容的所有函數(shù)和仿函數(shù),例如：
1: int f1(int); //這是個(gè)函數(shù)，形式為 int(int)
2: short f2(double); //這個(gè)函數(shù)形式為 short(double)
3: struct functor //這是個(gè)仿函數(shù)類，形式為int(int)
4: { 5: int operator()(int){} 6: };
7: functor f3; //創(chuàng)建仿函數(shù)對(duì)象
8: boost::function func; // int(int)型的函數(shù)或仿函數(shù)
9: func = f1; //接受f1
10: func(10); //調(diào)用f1(10)
11: func = f2; //也能接受short(double)型的f2
12: func(10); //調(diào)用f2(10)
13: func = f3; //也能接受仿函數(shù)f3
14: func(10); //調(diào)用f3(10)
- function應(yīng)能夠和參數(shù)綁定以及其它function-construction庫(kù)協(xié)同工作。例如，function應(yīng)該也能夠接受std::bind1st返回的仿函數(shù)。這一點(diǎn)其實(shí)由第一點(diǎn)已經(jīng)有所保證。
- 當(dāng)接受的一個(gè)空的仿函數(shù)對(duì)象被調(diào)用的時(shí)候function應(yīng)該有可預(yù)期的行為。
顯然，第一點(diǎn)是我們的重點(diǎn)，所謂形式兼容，就是說(shuō)，對(duì)于： R1 (T0,T1,T2,...,TN) => FunctionType1 R2 (P0,P1,P2,...,PN) => FunctionType2 兩種類型的函數(shù)（廣義），只要滿足：
- R2能夠隱式轉(zhuǎn)換為R1
- 所有Ti都能夠隱式轉(zhuǎn)換為Pi (i取0,1,2,...)
那么就說(shuō)，boost::function可以接受FunctionType2類型的函數(shù)(注意，反之不行)。支持這一論斷的理由是，只要Ti能夠隱式轉(zhuǎn)型為Pi，那么參數(shù)被轉(zhuǎn)發(fā)給真實(shí)的函數(shù)調(diào)用就是安全的，并且如果R2能夠隱式轉(zhuǎn)型為R1，那么返回真實(shí)函數(shù)調(diào)用所返回的值就是安全的。這里安全的含義是，C++類型系統(tǒng)認(rèn)為隱式轉(zhuǎn)換不會(huì)丟失信息，或者會(huì)給出編譯警告，但能夠通過(guò)編譯。 后面你會(huì)看到，boost::function通過(guò)所謂的invoker非常巧妙地實(shí)現(xiàn)了這點(diǎn)，并且阻止了被形式不兼容的函數(shù)賦值的操作。
探險(xiǎn)
好吧，準(zhǔn)備好，我們要出發(fā)了，進(jìn)行深入源碼世界的探險(xiǎn)。先看一個(gè)function的最簡(jiǎn)單的使用：
1: int g(int); //為了讓代碼簡(jiǎn)單，假設(shè)g有定義，以后的代碼都會(huì)如此
2: unction f(g);
3: f(0);
間奏——R(T1,T2,...)函數(shù)類型
雖然這個(gè)間奏未免早了點(diǎn)兒，但是為了讓你以后不會(huì)帶著迷惑，這顯然是必要的。請(qǐng)保持耐心。
或許你會(huì)對(duì)模板參數(shù)int(int)感到陌生，其實(shí)它是個(gè)函數(shù)型別——函數(shù)g的確切型別就是int(int)，而我們通常所看到的函數(shù)指針型別int (*)(int)則是&g的型別。它們的區(qū)別與聯(lián)系在于：當(dāng)把g作為一個(gè)值進(jìn)行拷貝的時(shí)候（例如，按值傳參），其類型就會(huì)由int(int)退化為int(*)(int)，即從函數(shù)類型退化為函數(shù)指針類型——因?yàn)閺恼Z(yǔ)義上說(shuō)，函數(shù)不能被“按值拷貝”，但身為函數(shù)指針的地址值則是可以被拷貝的。另一方面，如果g被綁定到引用，則其類型不會(huì)退化，仍保持函數(shù)類型。例如：
1: template void test_func_type(T ft) //按值傳遞，類型退化
2: { 3: static_cast(ft); //引發(fā)編譯錯(cuò)誤，從而看出ft的類型為退化后的函數(shù)指針
4: }
5:
6: int g(int); //函數(shù)g，名字g的類型為int(int)
7: test_func_type(g); //注意，并非&g，參數(shù)g的類型將會(huì)退化為函數(shù)指針類型
8: int (&ref_f)(int) = g; //注意，并非“= &g”，因?yàn)榻壎ǖ揭茫愋筒⒉煌嘶 ?/pre>
當(dāng)然，這樣的代碼不能通過(guò)編譯，因?yàn)閟tatic_cast<>顯然不會(huì)讓一個(gè)函數(shù)指針轉(zhuǎn)換為int，然而我們就是要它通不過(guò)編譯，這樣我們才能窺視到按值傳遞的參數(shù)ft的類型到底是什么，從編譯錯(cuò)誤中我們看出，ft的類型是int(*)(int)，也就是說(shuō)，在按值傳遞的過(guò)程中，g的類型退化為函數(shù)指針類型，變得和&g的類型一樣了。而ref_t的類型則是引用，引用綁定則沒(méi)有引起類型退化。 請(qǐng)注意，函數(shù)類型乃是個(gè)極其特殊的類型，在大多數(shù)時(shí)候它都會(huì)退化為函數(shù)指針類型，以便滿足拷貝語(yǔ)義，只有面對(duì)引用綁定的時(shí)候，能夠維持原來(lái)的類型。當(dāng)然，對(duì)于boost::function，總是按值拷貝。
繼續(xù)旅程
好吧，回過(guò)神來(lái)，我們還有更多地帶要去探究。
function實(shí)際上進(jìn)行了模板偏特化，Boost庫(kù)給function的類聲明為：
1: template<typename Signature, //函數(shù)類型
2: typename Allocator = ...
3: > //Allocator并非重點(diǎn)，故不作介紹
4: class function;
事實(shí)上function類只是個(gè)薄薄的外覆（wrapper），真正起作用的是偏特化版本。 對(duì)于function形式，偏特化版本的function源碼像這樣(實(shí)際上在boost源代碼中你看不到模板參數(shù)T0的聲明，也看不到function1，它們被宏替換掉了，那些精巧的宏是為了減小可見(jiàn)的代碼量，至于它們的細(xì)節(jié)則又是一個(gè)世界，以下代碼可看作對(duì)將那些令人眼花繚亂的宏展開(kāi)后所得到的代碼，具有更好的可讀性)：
1: //摘自：”boost/function/function_template.hpp”
2: template<typename R,typename T0,typename Allocator>
3: class function<R(T0),Allocator> //對(duì)R(T0)函數(shù)類型的偏特化版本
4: :public function1<R,T0,Allocator> //為R(T0)形式的函數(shù)準(zhǔn)備的基類，在下面討論
5: { 6: typedef function1<R,T0,Allocator> base_type;
7: typedef function selftype;
8: struct clear_type{}; //馬上你會(huì)看到這個(gè)蹊蹺的類型定義的作用 9:
10: public:
11: function() : base_type() {} //默認(rèn)構(gòu)造 12: template<typename Functor> //模板化的構(gòu)造函數(shù)，為了能夠接受形式兼容的仿函數(shù)對(duì)象
13: function(Functor f, typename enable_if<
14: (ice_not<(is_same<Functor, int>::value)>::value),
15: int
16: >::type = 0) ：base_type(f){} 17:
18: function(clear_type*) : base_type() {} //這個(gè)構(gòu)造函數(shù)的作用在下面解釋 19: self_type& operator=(const self_type& f) //同類型function對(duì)象之間應(yīng)該能夠賦值
20: { 21: self_type(f).swap(*this); //swap技巧，細(xì)節(jié)見(jiàn)《Effective STL》
22: return *this;
23: }
24: ...
25: };
26: enable_if
你一定對(duì)模板構(gòu)造函數(shù)中出現(xiàn)的那個(gè)冗長(zhǎng)的enable_if<...>的作用心存疑惑，其實(shí)它的作用說(shuō)穿了很簡(jiǎn)單，就是：當(dāng)用戶構(gòu)造：
function f(0);
的時(shí)候，將該（帶有enable_if的）構(gòu)造函數(shù)從重載決議的候選集中踢掉。使重載決議的結(jié)果為選中第三個(gè)構(gòu)造函數(shù)：
function(clear_type*):base_type(){}
從而進(jìn)行缺省構(gòu)造。 而說(shuō)得冗長(zhǎng)一點(diǎn)就是：當(dāng)f的類型——Functor——不是int時(shí)，該構(gòu)造函數(shù)就是“有效（enable）”的，會(huì)被重載決議選中。但如果用戶提供了一個(gè)0，用意是構(gòu)造一個(gè)空(null)的函數(shù)指針，那么該函數(shù)就會(huì)由于“SFINAE”原則而被從重載決議的候選函數(shù)中踢掉。為什么要這樣呢？因?yàn)樵摌?gòu)造函數(shù)負(fù)責(zé)把確切的f保存起來(lái)，它假定f并非0。那應(yīng)該選擇誰(shuí)呢？第三個(gè)構(gòu)造函數(shù)！其參數(shù)類型是clear_type*，當(dāng)然，0可以被賦給任何指針，所以它被選出，執(zhí)行缺省的構(gòu)造行為。
基類 functionN
function的骨架就這些。也許你會(huì)問(wèn)，function作為一個(gè)仿函數(shù)類，怎么沒(méi)有重載operator()——這可是身為仿函數(shù)的標(biāo)志啊！別急，function把這些煩人的任務(wù)都丟給了它的基類functionN，根據(jù)情況不同，N可能為0，1，2...，說(shuō)具體一點(diǎn)就是：根據(jù)用戶使用function時(shí)給出的函數(shù)類型，function將會(huì)繼承自不同的基類——如果用戶給出的函數(shù)類型為“R()”形式的，即僅有一個(gè)參數(shù)，則function繼承自function0，而對(duì)于R(T0)形式的函數(shù)類型，則繼承自function1，依此類推。前面說(shuō)過(guò)，function只是一層外覆，而所有的秘密都在其基類functionN中！
不知道你有沒(méi)有發(fā)現(xiàn)，function的骨架中也幾乎沒(méi)有用到函數(shù)類型的信息，事實(shí)上，它也將這些信息一股腦兒拋給了基類。在這過(guò)程中，混沌一團(tuán)的int(int)型別被拆解為兩個(gè)單獨(dú)的模板參數(shù)傳給基類:
1: template<typename R,typename T0,typename Allocator>
2: class function<R(T0),Allocator> //R(T0)整個(gè)為一型別
3: :public function1<R,T0,Allocator> //拆解為兩個(gè)模板參數(shù)R,T0傳給基類
好了，下面我們深入基類function1。真正豐富的寶藏在里面。
function1
function1的源代碼像這樣(與上面一樣，事實(shí)上有些代碼你是看不到的，為了不讓你迷惑，我給出的是將宏展開(kāi)后得到的代碼):
1: //摘自：”boost/function/function_template.hpp”
2: template<typename R,typename T0,class Allocator = ...>
3: class function1:public function_base //function_base負(fù)責(zé)管理內(nèi)存
4: { 5: ...
6: public:
7: typedef R result_type; //返回類型
8: typedef function1 self_type;
9:
10: function1() : function_base(),invoker(0){}//默認(rèn)構(gòu)造 11:
12: template<typename Functor>//模板構(gòu)造函數(shù)
13: function1(Functor const & f, typename enable_if<...>::type = 0) : function_base(), invoker(0)
14: { 15: this->assign_to(f); //這兒真正進(jìn)行賦值，assign_to的代碼在下面列出
16: }
17: function1(clear_type*) : function_base(), invoker(0){} //該構(gòu)造函數(shù)上面解釋過(guò) 18:
19: function1(const function& f) : //拷貝構(gòu)造函數(shù)
20: function_base(),invoker(0)
21: { 22: this->assign_to_own(f); //專用于在function之間賦值的assignment
23: }
24:
25: result_type operator()(T0 a0) const //身為仿函數(shù)的標(biāo)志！
26: { //下面負(fù)責(zé)調(diào)用指向的函數(shù) 27: if (this->empty())
28: boost::throw_exception(bad_function_call());
29: //這里進(jìn)行真正的函數(shù)調(diào)用，使用invoker
30: internal_result_type result = invoker(function_base::functor,a0);
31: return static_cast<result_type>(result);
32: }
33: template<typename Functor>
34: void assign_to(Functor f) //所有的構(gòu)造函數(shù)都調(diào)用它！具有多個(gè)重載版本。
35: { 36: //以一個(gè)get_function_tag萃取出Functor的類別(category)!
37: typedef typename detail::function::get_function_tag<Functor>::type tag;
38: this->assign_to(f, tag());//根據(jù)不同類別的Functor采取不同的assign策略！
39: }
40: get_function_tag<>能萃取出Functor的類別(category)，有下面幾種類別
41: struct function_ptr_tag {}; //函數(shù)指針類別 42: struct function_obj_tag {}; //仿函數(shù)對(duì)象類別 43: struct member_ptr_tag {}; //成員函數(shù)類別 44: struct function_obj_ref_tag {};//以ref(obj)加以封裝的類別，具有引用語(yǔ)義 45: struct stateless_function_obj_tag {}; //無(wú)狀態(tài)函數(shù)對(duì)象 46: 滿足以下所有條件：
47: has_trivial_constructor
48: has_trivial_copy
49: has_trivial_destructor
50: is_empty
51: 的仿函數(shù)對(duì)象稱為stateless的
52: 而對(duì)于不同的函數(shù)類別，assign_to有各個(gè)不同的重載版本，如下：
53: template<typename FunctionPtr> //如果是函數(shù)指針就調(diào)用這個(gè)版本
54: ? void assign_to(FunctionPtr f, function_ptr_tag) //這個(gè)版本針對(duì)函數(shù)指針
55: { 56: clear();
57: if (f){ 58: typedef typename detail::function::get_function_invoker1<
59: FunctionPtr,R,T0>::type invoker_type;
60: invoker = &invoker_type::invoke; //invoke是static成員函數(shù)
61: function_base::manager = //管理策略
62: &detail::function::functor_manager<FunctionPtr, Allocator>::manage;
63: function_base::functor = //交給function的函數(shù)指針或仿函數(shù)對(duì)象指針最終在這兒保存
64: function_base::manager(
65: detail::function::make_any_pointer((void (*)())(f)),
66: detail::function::clone_functor_tag);//實(shí)際上拷貝了一份函數(shù)指針
67: }
68: }
69: ...
70: typedef internal_result_type (*invoker_type)(detail::function::any_pointer,T0);
71: invoker_type invoker; //重要成員，負(fù)責(zé)調(diào)用函數(shù)！
72: };
你可能已經(jīng)被這段“夾敘夾議”的代碼弄得頭昏腦漲了，但這才剛剛開(kāi)始！
function的底層存儲(chǔ)機(jī)制
請(qǐng)將目光轉(zhuǎn)向上面的代碼段末尾的assign_to函數(shù)中，其中有兩行深色的代碼，分別對(duì)function_base里的manager和functor成員賦值。這兩行代碼肩負(fù)了保存各種函數(shù)指針的任務(wù)。
manager是一個(gè)函數(shù)指針，它所指向的函數(shù)代表管理策略，例如，對(duì)于函數(shù)指針，僅僅作一次賦值，就保存完畢了，但是對(duì)于仿函數(shù)，得額外分配一次內(nèi)存，然后將仿函數(shù)拷貝到分配的內(nèi)存中，這才完成了保存的任務(wù)。這些策略根據(jù)函數(shù)的類別而定，上面代碼中的assign_to函數(shù)是針對(duì)函數(shù)指針類別的重載版本，所以manager的策略是不作任何內(nèi)存分配，直接返回被轉(zhuǎn)型為“void(*)()”（利于在底層以統(tǒng)一的形式保存）的函數(shù)指針就行了，這從代碼中可以看出。
需要說(shuō)明的是，對(duì)于函數(shù)指針，function_base并不知道也不關(guān)心它要保存的函數(shù)指針是什么確切的類型，只要是函數(shù)指針就行，因?yàn)樗倳?huì)把該函數(shù)指針f轉(zhuǎn)型為“void (*)()”類型，然后保存在functor成員中，functor成員是一個(gè)union:
1: union any_pointer
2: { 3: void* obj_ptr; //任意仿函數(shù)對(duì)象指針都可以用static_cast<>轉(zhuǎn)型為void*型
4: const void* const_obj_ptr; //為const仿函數(shù)準(zhǔn)備的
5: void (*func_ptr)(); //任意函數(shù)指針都可以用reinterpret_cast<>轉(zhuǎn)型為void(*)()型
6: char data[1];
7: };
這個(gè)any_pointer可以通過(guò)安全轉(zhuǎn)型保存所有形式的仿函數(shù)和函數(shù)指針，承載在底層保存數(shù)據(jù)的任務(wù)
function的調(diào)用機(jī)制——invoker
我們把目光轉(zhuǎn)到function1的定義的最底部，那兒定義了它最重要的成員invoker，它是一個(gè)函數(shù)指針，所指向的函數(shù)就是function的調(diào)用機(jī)制所在，invoker的類型為：
1: typedef internal_result_type (*invoker_type)(any_pointer,T0);
前面已經(jīng)說(shuō)過(guò)，any_pointer是個(gè)union，可以保存任何類型的函數(shù)指針或函數(shù)對(duì)象，里面保存的是用戶注冊(cè)的函數(shù)或仿函數(shù)，T0為調(diào)用any_pointer中的函數(shù)的參數(shù)的型別（對(duì)于不同情況，可能會(huì)有T1,T2等）。這也就是說(shuō)，invoker負(fù)責(zé)調(diào)用保存在any_pointer中的用戶提供的函數(shù)或仿函數(shù)。 那么，invoker這個(gè)函數(shù)指針到底指向什么函數(shù)呢——也就是說(shuō)，在什么時(shí)候invoker被賦值了呢？我們?cè)俅伟涯抗廪D(zhuǎn)向assign_to函數(shù)，其中有一行對(duì)invoker成員賦值的語(yǔ)句，從這行語(yǔ)句出發(fā)我們可以揭露invoker的全部奧秘：
1: invoker = &invoker_type::invoke; //invoke是static成員函數(shù)
請(qǐng)不要把這個(gè)invoker_type和上面那個(gè)函數(shù)指針型別invoker_type混淆起來(lái)，這個(gè)invoker_type是位于assign_to函數(shù)中的一個(gè)局部的typedef，所以隱藏了后者（即類作用域中的那個(gè)invoker_type——invoker成員的類型）。往上一行，你就看到這個(gè)局部型別invoker_type的定義了：
1: typedef typename get_function_invoker1<FunctionPtr,R,T0>::type invoker_type;
get_function_invoker1又是何物？很顯然，這是個(gè)traits，其內(nèi)嵌的::type會(huì)根據(jù)不同的模板參數(shù)表現(xiàn)為不同的類型，在本例中，::type的類型將會(huì)被推導(dǎo)為 function_invoker1 而function_invoker1是個(gè)類模板，其定義為：
1: template<typename FunctionPtr,
2: typename R，typename T0> //注意這里的模板參數(shù)，后面會(huì)解釋
3: struct function_invoker1
4: { 5: static R invoke(any_pointer function_ptr,T0 a0)
6: { 7: FunctionPtr f = reinterpret_cast<FunctionPtr>(function_ptr.func_ptr);
8: return f(a0);
9: }
10: };
所以對(duì)invoker的賦值最終相當(dāng)于：
invoker=&function_invoker1::invoke;
而function_invoker1::invoke是靜態(tài)成員函數(shù)，它被實(shí)例化后相當(dāng)于：
1: static int invoke(any_pointer function_ptr,int a0)
2: { 3: //先轉(zhuǎn)型，再調(diào)用，注意，這一行語(yǔ)句還有一個(gè)額外的作用，在后面解釋
4: int (*f)(int) = reinterpret_cast(function_ptr.func_ptr);
5: //因?yàn)閒指向的是用戶保存在該function中的函數(shù)或仿函數(shù)，所以這一行語(yǔ)句進(jìn)行了真實(shí)的調(diào)用！
6: return f(a0);
7: }
我們可以看出，在invoke函數(shù)中，真正的調(diào)用現(xiàn)身了。
如果接受的是仿函數(shù)，則有function_obj_invoker1與它對(duì)應(yīng)，后者也是一個(gè)類似的模板，它的invoke靜態(tài)成員函數(shù)的形式也是：
static R invoke(any_pointer function_obj_ptr,T0 a0);
其中function_obj_ptr是指向仿函數(shù)的指針，所以其invoke靜態(tài)成員函數(shù)中對(duì)它的調(diào)用語(yǔ)句是這樣的：
1: FunctionObj* f = (FunctionObj*)(function_obj_ptr.obj_ptr);
2: return (*f)(a0); //調(diào)用用戶的仿函數(shù)
最后一種可能：如果接受的是成員函數(shù)怎么辦呢？簡(jiǎn)單的答案是：boost::function并沒(méi)有為成員函數(shù)作任何特殊準(zhǔn)備！理由也很簡(jiǎn)單，boost::function只要先將成員函數(shù)封裝為仿函數(shù)，然后將其作為一般的仿函數(shù)對(duì)待就行了，具體代碼就不列了，STL中有一個(gè)函數(shù)模板std::mem_fun就是用于封裝成員函數(shù)指針的，它返回的是一個(gè)仿函數(shù)。boost中也對(duì)該函數(shù)模板做了擴(kuò)充，使它可以接受任意多個(gè)參數(shù)的成員函數(shù)。
做一個(gè)，送一個(gè)——invoker的額外好處
我們注意到function的構(gòu)造和賦值函數(shù)及其基類的構(gòu)造和賦值函數(shù)都是模板函數(shù)，這是因?yàn)橛脩艨赡芴峁┖瘮?shù)也可能提供函數(shù)模板，但最關(guān)鍵的還是，functiont提供一種能力：對(duì)于function類型的泛型函數(shù)指針，用戶可以給它一個(gè)int(int)類型的函數(shù)——是的，這是可行且安全的，因?yàn)槠浞祷刂殿愋蚷nt可以安全的轉(zhuǎn)型為double，而對(duì)于這種類型兼容性的檢查就在上面分析的invoke靜態(tài)成員函數(shù)中，這就是我們要說(shuō)的額外好處——如果類型兼容，那么invoke函數(shù)就能正常編譯通過(guò)，但如果用戶給出類型不兼容的函數(shù)，就會(huì)得到一個(gè)錯(cuò)誤，這個(gè)錯(cuò)誤是在編譯器實(shí)例化invoke函數(shù)代碼的時(shí)候給出的，例如，用戶如果這樣寫：
1: RT1 f(P1,P2); // RT1(P1,P2)函數(shù)類型，這里的RT1,P1,P2假定已經(jīng)定義，這是一般化的符號(hào)
2: function f_ptr;
3: //RT(P)函數(shù)類型，同樣假定RT,P已定義
4: f_ptr = &f; //類型不兼容，錯(cuò)誤！
這就會(huì)導(dǎo)致編譯錯(cuò)誤，錯(cuò)誤發(fā)生在invoke靜態(tài)成員函數(shù)中。下面我就為你解釋為什么。
我想你對(duì)function_invoker1考的三個(gè)模板參數(shù)仍然心存疑惑，我們?cè)僖淮蝸?lái)回顧一下其聲明：
1: template<typename FunctionPtr,typename R，typename T0> struct function_invoker1
我們還得把目光投向assign_to模板函數(shù)，其中使用function_invoker1的時(shí)候是這樣的：
1: typedef typename detail::function::get_function_invoker1< FunctionPtr,R,T0>::type invoker_type;
這里，給出的FunctionPtr,R,T0三個(gè)模板參數(shù)將會(huì)原封不動(dòng)的傳給function_invoker1，那么對(duì)于我們上面的錯(cuò)誤示例，這三個(gè)模板參數(shù)各是什么呢？
首先，我們很容易看出，F(xiàn)unctionPtr就是assign_to模板函數(shù)的模板參數(shù)，也就是用戶傳遞的函數(shù)或仿函數(shù)的類型，在我們的錯(cuò)誤示例中，函數(shù)f的類型為RT1(P1,P2)，所以 FunctionPtr = RT1(*)(P1,P2)
而R,T0則是用戶在實(shí)例化function模板時(shí)給出的模板參數(shù)，我們寫的是function
R = RT
T0 = P
所以，對(duì)于我們的錯(cuò)誤示例，invoker_type的類型為：
function_invoker1< RT1(*)(P1,P2),RT,P>
對(duì)于這樣一個(gè)function_invoker1，其內(nèi)部的invoke靜態(tài)成員函數(shù)被實(shí)例化為：
1: static RT invoke(any_pointer function_ptr,P a0)
2: { 3: RT1 (*f)(P1,P2)= //FunctorPtr f =
4: reinterpret_cast<RT1(*)(P1,P2)>(function_ptr.func_ptr);
5:
6: return f(a0); //錯(cuò)啦！瞧瞧f的型別，f接受一個(gè)P類型的參數(shù)嗎？編譯器在此打住。
7: //這行語(yǔ)句的另一個(gè)隱含的檢查是返回值類型匹配，f(...)返回RT1，而invoke須得返回RT
8: }
看看最后一行語(yǔ)句，所有的檢查都在那里了——我們最終把檢查“委托”給了C++底層的類型系統(tǒng)。
很精妙不是嗎？雖然在模板形式的assign_to函數(shù)中，看起來(lái)我們并不關(guān)心到底用戶給的參數(shù)是何類型，看起來(lái)用戶可以把任何函數(shù)或仿函數(shù)塞過(guò)來(lái)，但是一旦下面觸及invoker的賦值，就得實(shí)例化invoke靜態(tài)成員函數(shù)，其中的：
return f(a0);
一下就把問(wèn)題暴露出來(lái)了！這種把類型檢查延遲到最后，不得不進(jìn)行的時(shí)候，由C++底層的類型系統(tǒng)來(lái)負(fù)責(zé)檢查的手法的確很奇妙——看起來(lái)我們沒(méi)有在assign_to函數(shù)中及時(shí)利用類型信息進(jìn)行類型檢查，但是我們卻并沒(méi)有喪失任何類型安全性，一切最終都逃不過(guò)C++底層的類型系統(tǒng)的考驗(yàn)！
function如何對(duì)待成員函數(shù)
對(duì)于成員函數(shù)，assign_to的重載版本只有一行：
1: this->assign_to(mem_fn(f));
mem_fun(f)返回一個(gè)仿函數(shù)，它封裝了成員函數(shù)f，之后一切皆與仿函數(shù)無(wú)異。
關(guān)于mem_fun的細(xì)節(jié)，這里就不多說(shuō)了，大家可以參考STL中的實(shí)現(xiàn)，相信很容易看懂，這里只簡(jiǎn)單的提醒一下，成員函數(shù)封裝的效果是這樣的：
R (C::*)(T0,T1,...) --> R (*)(C*,T0,T1,...) 或 R (*)(C&,T0,T1,...)
safe_bool慣用手法
如你所知，對(duì)于函數(shù)指針fptr，我們可以這樣測(cè)試它：if(fptr) ...，所以function也應(yīng)該提供這一特性，然而如果直接重載operator bool()則會(huì)導(dǎo)致下面的代碼成為合法的:
1:
2: function f;
3: bool b=f;
這顯然不妥，所以function用另一個(gè)巧妙的手法替代它，既所謂的safe_bool慣用手法，這在function定義內(nèi)部的源碼如下：
1: struct dummy { void nonnull(){};}; 2: typedef void (dummy::*safe_bool)(); //確保safebool不能轉(zhuǎn)型為任何其它類型！
3: operator safe_bool () const
4: { 5: return (this->empty())? 0 : &dummy::nonnull;
6: }
這樣，當(dāng)你寫if(f)的時(shí)候，編譯器會(huì)找到operator safe_bool()，從而將f轉(zhuǎn)型為safe_bool，這是個(gè)指針類型，if語(yǔ)句會(huì)正確判定它是否為空。而當(dāng)你試圖把f賦給其它類型的變量的時(shí)候則會(huì)遭到編譯期的拒絕——因?yàn)閟afe_bool無(wú)法向其它類型轉(zhuǎn)換。
get_function_tag<>
get_function_tag<>用于萃取出函數(shù)所屬類別(category)，各個(gè)類別在源代碼中已經(jīng)列出，至于它到底是如何萃取的，這與本文關(guān)系不是很大，有一點(diǎn)需要提醒一下：函數(shù)指針類型也是指針類型，這聽(tīng)起來(lái)完全是句廢話，但是考慮這樣的代碼：
1: template struct is_pointer{enum{value=0};}; 2: mplate struct is_pointer{enum{value=1};}; 3: d::cout<::value; //這將輸出 1
也就是說(shuō)int(*)(int)可以與T*形式匹配，匹配時(shí)T為int(int)。
最后一些細(xì)節(jié)
1. 我沒(méi)有給出function_base的源代碼，實(shí)際上那很簡(jiǎn)單，它最主要的成員就是union any_pointer型的數(shù)據(jù)成員
detail::function::any_pointer functor; //用于統(tǒng)一保存函數(shù)指針及仿函數(shù)對(duì)象指針
2. 我沒(méi)有給出functor_manager的信息，實(shí)際上它與function的實(shí)現(xiàn)沒(méi)有太大關(guān)系，它負(fù)責(zé)copy和delete函數(shù)對(duì)象，如果必要的話。所以我將它略去，它的源碼在：”boost/function/function_base.hpp”里。
3. 我給出的源代碼是將宏展開(kāi)后的版本，實(shí)際的代碼中充斥著讓人眼花繚亂的宏，關(guān)于那些宏則又是一個(gè)奇妙的世界。Boost庫(kù)通過(guò)那些宏省去了許多可見(jiàn)代碼量。隨著函數(shù)參數(shù)的不同，那些宏會(huì)擴(kuò)展出function2,function3...各個(gè)版本。
本文只研究了int(int)型的情況，其它只是參數(shù)數(shù)目的改變而已。經(jīng)過(guò)宏的擴(kuò)展，function的偏特化版本將有:
1: template<typename R,typename Allocator>
2: class function<R(),Allocator>:public function0<R,Allocator>
3: {...}; 4: template<typename R,typename T0,typename Allocator>
5: class function<R(T0),Allocator>:public function1<R,T0,Allocator>
6: {...}; 7: template<typename R,typename T0,typename T1,typename Allocator>
8: class function<R(T0,T1),Allocator>:public function2<R,T0,T1,Allocator>
9: {...};
等更多版本，一共有BOOST_FUNCTION_MAX_ARGS+1個(gè)版本，BOOST_FUNCTION_MAX_ARGS為一個(gè)宏，表示最多能夠接受有多少個(gè)參數(shù)的函數(shù)及仿函數(shù)對(duì)象，你可以重新定義這個(gè)宏為一個(gè)新值，以控制function所能支持的函數(shù)參數(shù)個(gè)數(shù)的最大值。其中的function0,function1,function2等名字也由宏擴(kuò)展出。 關(guān)于作者： 劉未鵬是南大的學(xué)生，喜愛(ài)關(guān)于C++的一切，另外還喜歡的是.NET，雖然C#很爛，但是.NET的確不錯(cuò)，正打算寫一個(gè)剖析Rotor(Shared source CLI)源代碼的系列，深掘.NET內(nèi)部的架構(gòu)及實(shí)現(xiàn)，但由于正忙于考研，不知何年何月才能開(kāi)始...
于 2004-10-2 23:24 修改完畢 :-)