Boost源碼剖析：C++泛型函數(shù)指針類

2019-11-17 05:10:51

字體：大中小

供稿：網(wǎng)友

前奏

　　如你所知，Boost庫是個特性完備，且具備工業(yè)強度的庫，眾多C++權(quán)威的參與使其達到了登峰造極的程度。尤其泛型的強大威力在其中被發(fā)揮得淋漓盡致，令人瞠目結(jié)舌。

　　然而弱水三千，我們只取一瓢飲。下面，我試圖從最單純的世界開始，一步一步帶領(lǐng)你進入源碼的世界，去探究boost::function(下文簡稱function)內(nèi)部的精微結(jié)構(gòu)。

　　通常，在單純的情況下，對函數(shù)的調(diào)用簡單而且直觀，像這樣：

int fun(int someVal);

int main(){
　fun(10);
}
　　然而你可能需要在某個時刻將函數(shù)指針保存下來，并在以后的另一個時刻調(diào)用它，像這樣：

int fun(int);
typedef int (*func_handle)(int);

int main(){
　func_handle fh=fun;
　... //do something
　fh(10);
}
　　但是，假如fun形式為void fun(int)呢？如你所見，fun可能有無數(shù)種形式，假如對fun的每一個形式都typedef一個對應的func_handle，則程序員會焦頭爛額，不勝其擾，代碼也可能變得臃腫和丑陋不堪，甚至假如fun是仿函數(shù)呢？

　　幸運的是C++泛型可以使代碼變得優(yōu)雅精致，面對無數(shù)種的可能，泛型是最好的選擇。因此，你只是需要一個能夠保存函數(shù)指針的泛型模板類(對應于Command模式)，因為泛型編程有一個先天性的優(yōu)勢——可以借助編譯器的力量在編譯期根據(jù)用戶提供的型別信息化身千萬(具現(xiàn)化)，所以一個泛型的類可以有無限個具現(xiàn)體，也就是說可以保存無限多種可能型別的函數(shù)或類似函數(shù)的東西(如，仿函數(shù))。這個類(在Boost庫中的類名為function)與函數(shù)指針相比應該有以下一些優(yōu)勢：

　　¨ 同一個function對象應能夠接受與它形式兼容的所有函數(shù)和仿函數(shù),例如：

int f1(int); //這是個函數(shù)，形式為 int(int)
short f2(double); //這個函數(shù)形式為 short(double)

strUCt functor //這是個仿函數(shù)類，形式為int(int)
{
　int Operator()(int){}
};

functor f3; //創(chuàng)建仿函數(shù)對象

boost::function＜int(int)＞ func; // int(int)型的函數(shù)或仿函數(shù)
func = f1; //接受f1
func(10); //調(diào)用f1(10)
func = f2; //也能接受short(double)型的f2
func(10); //調(diào)用f2(10)
func = f3; //也能接受仿函數(shù)f3
func(10); //調(diào)用f3(10)
　　¨ function應能夠和參數(shù)綁定以及其它function-construction庫協(xié)同工作。例如，function應該也能夠接受std::bind1st返回的仿函數(shù)。這一點其實由第一點已經(jīng)有所保證。

　　¨ 當接受的一個空的仿函數(shù)對象被調(diào)用的時候function應該有可預期的行為。

　　顯然，第一點是我們的重點，所謂形式兼容，就是說，對于：

R1 (T0,T1,T2,...,TN) =＞ FunctionType1
R2 (P0,P1,P2,...,PN) =＞ FunctionType2
　　兩種類型的函數(shù)（廣義），只要滿足：

　　1. R2能夠隱式轉(zhuǎn)換為R1

　　2. 所有Ti都能夠隱式轉(zhuǎn)換為Pi (i取0,1,2,...)

　　那么就說，boost::function＜FunctionType1＞可以接受FunctionType2類型的函數(shù)(注重，反之不行)。支持這一論斷的理由是，只要Ti能夠隱式轉(zhuǎn)型為Pi，那么參數(shù)被轉(zhuǎn)發(fā)給真實的函數(shù)調(diào)用就是安全的，并且假如R2能夠隱式轉(zhuǎn)型為R1，那么返回真實函數(shù)調(diào)用所返回的值就是安全的。這里安全的含義是，C++類型系統(tǒng)認為隱式轉(zhuǎn)換不會丟失信息，或者會給出編譯警告，但能夠通過編譯。

　　后面你會看到，boost::function通過所謂的invoker非常巧妙地實現(xiàn)了這點，并且阻止了被形式不兼容的函數(shù)賦值的操作。

更多內(nèi)容請看C/C++技術(shù)專題專題，或

探險

　　好吧，預備好，我們要出發(fā)了，進行深入源碼世界的探險。

　　先看一個function的最簡單的使用：

int g(int); //為了讓代碼簡單，假設(shè)g有定義，以后的代碼都會如此
function＜int(int)＞ f(g);
f(0);
　　間奏——R(T1,T2,...)函數(shù)類型

　　雖然這個間奏未免早了點兒，但是為了讓你以后不會帶著迷惑，這顯然是必要的。請保持耐心。

　　或許你會對模板參數(shù)int(int)感到生疏，其實它是個函數(shù)型別——函數(shù)g的確切型別就是int(int)，而我們通常所看到的函數(shù)指針型別int (*)(int)則是&g的型別。它們的區(qū)別與聯(lián)系在于：當把g作為一個值進行拷貝的時候（例如，按值傳參），其類型就會由int(int)退化為int(*)(int)，即從函數(shù)類型退化為函數(shù)指針類型——因為從語義上說，函數(shù)不能被“按值拷貝”，但身為函數(shù)指針的地址值則是可以被拷貝的。另一方面，假如g被綁定到引用，則其類型不會退化，仍保持函數(shù)類型。例如：

template＜class T＞

void test_func_type(T ft) //按值傳遞，類型退化
{
　static_cast＜int＞(ft); //引發(fā)編譯錯誤，從而看出ft的類型為退化后的函數(shù)指針
}

int g(int); //函數(shù)g，名字g的類型為int(int)
test_func_type(g); //注重，并非&g，參數(shù)g的類型將會退化為函數(shù)指針類型
int (&ref_f)(int) = g; //注重，并非“= &g”，因為綁定到引用，類型并不退化
　　當然，這樣的代碼不能通過編譯，因為static_cast＜＞顯然不會讓一個函數(shù)指針轉(zhuǎn)換為int，然而我們就是要它通不過編譯，這樣我們才能窺視到按值傳遞的參數(shù)ft的類型到底是什么，從編譯錯誤中我們看出，ft的類型是int(*)(int)，也就是說，在按值傳遞的過程中，g的類型退化為函數(shù)指針類型，變得和&g的類型一樣了。而ref_t的類型則是引用，引用綁定則沒有引起類型退化。

　　請注重，函數(shù)類型乃是個極其非凡的類型，在大多數(shù)時候它都會退化為函數(shù)指針類型，以便滿足拷貝語義，只有面對引用綁定的時候，能夠維持原來的類型。當然，對于boost::function，總是按值拷貝。

　　繼續(xù)旅程

　　好吧，回過神來，我們還有更多地帶要去探究。

　　function＜int(int)＞實際上進行了模板偏特化，Boost庫給function的類聲明為：

template＜typename Signature, //函數(shù)類型
typename Allocator = ...
＞ //Allocator并非重點，故不作介紹

class function;
　　事實上function類只是個薄薄的外覆（wrapper），真正起作用的是偏特化版本。

　　對于function＜R(T0)＞形式，偏特化版本的function源碼像這樣(實際上在boost源代碼中你看不到模板參數(shù)T0的聲明，也看不到function1，它們被宏替換掉了，那些精巧的宏是為了減小可見的代碼量，至于它們的細節(jié)則又是一個世界，以下代碼可看作對將那些令人眼花繚亂的宏展開后所得到的代碼，具有更好的可讀性)：

　　摘自：”boost/function/function_template.hpp”

template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞ //對R(T0)函數(shù)類型的偏特化版本

:public function1＜R,T0,Allocator＞ //為R(T0)形式的函數(shù)預備的基類，在下面討論
{
　typedef function1＜R,T0,Allocator＞ base_type;
　typedef function selftype;
　struct clear_type{}; //馬上你會看到這個蹊蹺的類型定義的作用
　public:
　　function() : base_type() {} //默認構(gòu)造
　　template＜typename Functor＞ //模板化的構(gòu)造函數(shù)，為了能夠接受形式兼容的仿函數(shù)對象
　　function(Functor f, typename enable_if＜
　　　　(ice_not＜(is_same＜Functor, int＞::value)＞::value),
　　　　int
　　＞::type = 0) ：base_type(f){}

　function(clear_type*) : base_type() {} //這個構(gòu)造函數(shù)的作用在下面解釋
　self_type& operator=(const self_type& f) //同類型function對象之間應該能夠賦值
　{
　　self_type(f).swap(*this); //swap技巧，細節(jié)見《Effective STL》
　　return *this;
　}
　...
};

enable_if

　　你一定對模板構(gòu)造函數(shù)中出現(xiàn)的那個冗長的enable_if＜...＞的作專心存迷惑，其實它的作用說穿了很簡單，就是：當用戶構(gòu)造：

function＜int(int)＞ f(0);
　　的時候，將該（帶有enable_if的）構(gòu)造函數(shù)從重載決議的候選集中踢掉。使重載決議的結(jié)果為選中第三個構(gòu)造函數(shù)：

function(clear_type*):base_type(){}
　　從而進行缺省構(gòu)造。而說得冗長一點就是：當f的類型——Functor——不是int時，該構(gòu)造函數(shù)就是“有效（enable）”的，會被重載決議選中。但假如用戶提供了一個0，用意是構(gòu)造一個空(null)的函數(shù)指針，那么該函數(shù)就會由于“SFINAE”原則而被從重載決議的候選函數(shù)中踢掉。為什么要這樣呢？因為該構(gòu)造函數(shù)負責把確切的f保存起來，它假定f并非0。那應該選擇誰呢？第三個構(gòu)造函數(shù)！其參數(shù)類型是clear_type*，當然，0可以被賦給任何指針，所以它被選出，執(zhí)行缺省的構(gòu)造行為。

更多內(nèi)容請看C/C++技術(shù)專題專題，或

基類 functionN

　　function的骨架就這些。也許你會問，function作為一個仿函數(shù)類，怎么沒有重載operator()——這可是身為仿函數(shù)的標志啊！別急，function把這些煩人的任務(wù)都丟給了它的基類functionN，根據(jù)情況不同，N可能為0，1，2...，說具體一點就是：根據(jù)用戶使用function時給出的函數(shù)類型，function將會繼續(xù)自不同的基類——假如用戶給出的函數(shù)類型為“R()”形式的，即僅有一個參數(shù)，則function繼續(xù)自function0，而對于R(T0)形式的函數(shù)類型，則繼續(xù)自function1，依此類推。前面說過，function只是一層外覆，而所有的秘密都在其基類functionN中！

　　不知道你有沒有發(fā)現(xiàn)，function的骨架中也幾乎沒有用到函數(shù)類型的信息，事實上，它也將這些信息一股腦兒拋給了基類。在這過程中，混沌一團的int(int)型別被拆解為兩個單獨的模板參數(shù)傳給基類:

template＜typename R,typename T0,typename Allocator＞
class function＜R(T0),Allocator＞ //R(T0)整個為一型別
:public function1＜R,T0,Allocator＞ //拆解為兩個模板參數(shù)R,T0傳給基類
　　好了，下面我們深入基類function1。真正豐富的寶藏在里面。

　　function1

　　function1的源代碼像這樣(與上面一樣，事實上有些代碼你是看不到的，為了不讓你迷惑，我給出的是將宏展開后得到的代碼):

　　摘自：”boost/function/function_template.hpp”

template＜typename R,typename T0,class Allocator = ...＞

class function1:public function_base //function_base負責治理內(nèi)存
{
　...
　public:
　　typedef R result_type; //返回類型
　　typedef function1 self_type;
　　function1() : function_base(),invoker(0){}//默認構(gòu)造
　　template＜typename Functor＞
　　function1(Functor const & f, //模板構(gòu)造函數(shù)
　　　typename enable_if＜...＞::type = 0) :
　　　function_base(),
　　　invoker(0)
　　　{
　　　　this-＞assign_to(f); //這兒真正進行賦值，assign_to的代碼在下面列出
　　　}

　　function1(clear_type*) : function_base(), invoker(0){} //該構(gòu)造函數(shù)上面解釋過
　　function1(const function& f) : //拷貝構(gòu)造函數(shù)
　　function_base(),
　　invoker(0){
　　　this-＞assign_to_own(f); //專用于在function之間賦值的assignment
　　}

　　result_type operator()(T0 a0) const //身為仿函數(shù)的標志！
　　{
　　　//下面負責調(diào)用指向的函數(shù)

　　　if (this-＞empty())
　　　　boost::throw_exception(bad_function_call());
　　　　//這里進行真正的函數(shù)調(diào)用，使用invoker

　　　　internal_result_type result = invoker(function_base::functor,a0);
　　　　return static_cast＜result_type＞(result);
　　}

　　template＜typename Functor＞
　　void assign_to(Functor f) //所有的構(gòu)造函數(shù)都調(diào)用它！具有多個重載版本。
　　{
　　　//以一個get_function_tag萃取出Functor的類別(category)!
　　　typedef typename detail::function::get_function_tag＜Functor＞::type tag;
　　　this-＞assign_to(f, tag());//根據(jù)不同類別的Functor采取不同的assign策略！
　　}
　　get_function_tag＜＞能萃取出Functor的類別(category)，有下面幾種類別

　　struct function_ptr_tag {}; //函數(shù)指針類別

　　struct function_obj_tag {}; //仿函數(shù)對象類別

　　struct member_ptr_tag {}; //成員函數(shù)類別

　　struct function_obj_ref_tag {};//以ref(obj)加以封裝的類別，具有引用語義

　　struct stateless_function_obj_tag {}; //無狀態(tài)函數(shù)對象

　　滿足以下所有條件：

　　has_trivial_constructor

　　has_trivial_copy

　　has_trivial_destructor

　　is_empty

　　的仿函數(shù)對象稱為stateless的

　　而對于不同的函數(shù)類別，assign_to有各個不同的重載版本，如下：

template＜typename FunctionPtr＞ //假如是函數(shù)指針就調(diào)用這個版本

void assign_to(FunctionPtr f, function_ptr_tag) //這個版本針對函數(shù)指針
{
　clear();
　if (f){
　　typedef typename detail::function::get_function_invoker1＜FunctionPtr,R,T0＞::type invoker_type;
　　invoker = &invoker_type::invoke; //invoke是static成員函數(shù)

　　function_base::manager = //治理策略
　　　　 &detail::function::functor_manager＜FunctionPtr, Allocator＞::manage;

　　function_base::functor = //交給function的函數(shù)指針或仿函數(shù)對象指針最終在這兒保存
　　　function_base::manager(
　　　　detail::function::make_any_pointer((void (*)())(f)),
　　　　detail::function::clone_functor_tag);//實際上拷貝了一份函數(shù)指針
　}
}

...

typedef internal_result_type (*invoker_type)(detail::function::any_pointer,T0);
invoker_type invoker; //重要成員，負責調(diào)用函數(shù)！

};
　　你可能已經(jīng)被這段“夾敘夾議”的代碼弄得頭昏腦漲了，但這才剛剛開始！

　　function的底層存儲機制

　　請將目光轉(zhuǎn)向上面的代碼段末尾的assign_to函數(shù)中，其中有兩行深色的代碼，分別對function_base里的manager和functor成員賦值。這兩行代碼肩負了保存各種函數(shù)指針的任務(wù)。

　　manager是一個函數(shù)指針，它所指向的函數(shù)代表治理策略，例如，對于函數(shù)指針，僅僅作一次賦值，就保存完畢了，但是對于仿函數(shù)，得額外分配一次內(nèi)存，然后將仿函數(shù)拷貝到分配的內(nèi)存中，這才完成了保存的任務(wù)。這些策略根據(jù)函數(shù)的類別而定，上面代碼中的assign_to函數(shù)是針對函數(shù)指針類別的重載版本，所以manager的策略是不作任何內(nèi)存分配，直接返回被轉(zhuǎn)型為“void(*)()”（利于在底層以統(tǒng)一的形式保存）的函數(shù)指針就行了，這從代碼中可以看出。

　　需要說明的是，對于函數(shù)指針，function_base并不知道也不關(guān)心它要保存的函數(shù)指針是什么確切的類型，只要是函數(shù)指針就行，因為它總會把該函數(shù)指針f轉(zhuǎn)型為“void (*)()”類型，然后保存在functor成員中，functor成員是一個union:

union any_pointer
{
void* obj_ptr; //任意仿函數(shù)對象指針都可以用static_cast＜＞轉(zhuǎn)型為void*型
const void* const_obj_ptr; //為const仿函數(shù)預備的
void (*func_ptr)(); //任意函數(shù)指針都可以用reinterPRet_cast＜＞轉(zhuǎn)型為void(*)()型
char data[1];
};
　　這個any_pointer可以通過安全轉(zhuǎn)型保存所有形式的仿函數(shù)和函數(shù)指針，承載在底層保存數(shù)據(jù)的任務(wù)

　　function的調(diào)用機制——invoker

　　我們把目光轉(zhuǎn)到function1的定義的最底部，那兒定義了它最重要的成員invoker，它是一個函數(shù)指針，所指向的函數(shù)就是function的調(diào)用機制所在，invoker的類型為：

typedef internal_result_type (*invoker_type)(any_pointer,T0);
　　前面已經(jīng)說過，any_pointer是個union，可以保存任何類型的函數(shù)指針或函數(shù)對象，里面保存的是用戶注冊的函數(shù)或仿函數(shù)，T0為調(diào)用any_pointer中的函數(shù)的參數(shù)的型別（對于不同情況，可能會有T1,T2等）。這也就是說，invoker負責調(diào)用保存在any_pointer中的用戶提供的函數(shù)或仿函數(shù)。

　　那么，invoker這個函數(shù)指針到底指向什么函數(shù)呢——也就是說，在什么時候invoker被賦值了呢？我們再次把目光轉(zhuǎn)向assign_to函數(shù)，其中有一行對invoker成員賦值的語句，從這行語句出發(fā)我們可以揭露invoker的全部奧秘：

invoker = &invoker_type::invoke; //invoke是static成員函數(shù)
　　請不要把這個invoker_type和上面那個函數(shù)指針型別invoker_type混淆起來，這個invoker_type是位于assign_to函數(shù)中的一個局部的typedef，所以隱藏了后者（即類作用域中的那個invoker_type——invoker成員的類型）。往上一行，你就看到這個局部型別invoker_type的定義了：

typedef typename get_function_invoker1＜

FunctionPtr,R,T0＞::type invoker_type;
　　get_function_invoker1又是何物？很顯然，這是個traits，其內(nèi)嵌的::type會根據(jù)不同的模板參數(shù)表現(xiàn)為不同的類型，在本例中，::type的類型將會被推導為

function_invoker1＜int(*)(int),int,int＞
　　而function_invoker1是個類模板，其定義為：

template＜typename FunctionPtr,
typename R，typename T0＞ //注重這里的模板參數(shù)，后面會解釋

struct function_invoker1
{
　static R invoke(any_pointer function_ptr,T0 a0)
　{
　　FunctionPtr f = reinterpret_cast＜FunctionPtr＞(function_ptr.func_ptr);
　　return f(a0);
　}
};
　　所以對invoker的賦值最終相當于：

invoker=&function_invoker1＜int(*)(int),int,int＞::invoke;
　　而function_invoker1＜int(*)(int),int,int＞::invoke是靜態(tài)成員函數(shù)，它被實例化后相當于：

static int invoke(any_pointer function_ptr,int a0)
{
　//先轉(zhuǎn)型，再調(diào)用，注重，這一行語句還有一個額外的作用，在后面解釋
　int (*f)(int) = reinterpret_cast＜int(*)(int)＞(function_ptr.func_ptr);

　//因為f指向的是用戶保存在該function中的函數(shù)或仿函數(shù)，所以這一行語句進行了真實的調(diào)用！
　return f(a0);
}
　　我們可以看出，在invoke函數(shù)中，真正的調(diào)用現(xiàn)身了。

　　假如接受的是仿函數(shù)，則有function_obj_invoker1與它對應，后者也是一個類似的模板，它的invoke靜態(tài)成員函數(shù)的形式也是：

static R invoke(any_pointer function_obj_ptr,T0 a0);
　　其中function_obj_ptr是指向仿函數(shù)的指針，所以其invoke靜態(tài)成員函數(shù)中對它的調(diào)用語句是這樣的：

FunctionObj* f = (FunctionObj*)(function_obj_ptr.obj_ptr);

return (*f)(a0); //調(diào)用用戶的仿函數(shù)
　　最后一種可能：假如接受的是成員函數(shù)怎么辦呢？簡單的答案是：boost::function并沒有為成員函數(shù)作任何非凡預備！理由也很簡單，boost::function只要先將成員函數(shù)封裝為仿函數(shù)，然后將其作為一般的仿函數(shù)對待就行了，具體代碼就不列了，STL中有一個函數(shù)模板std::mem_fun就是用于封裝成員函數(shù)指針的，它返回的是一個仿函數(shù)。boost中也對該函數(shù)模板做了擴充，使它可以接受任意多個參數(shù)的成員函數(shù)。

更多內(nèi)容請看C/C++技術(shù)專題專題，或

做一個，送一個——invoker的額外好處

　　我們注重到function的構(gòu)造和賦值函數(shù)及其基類的構(gòu)造和賦值函數(shù)都是模板函數(shù)，這是因為用戶可能提供函數(shù)也可能提供函數(shù)模板，但最要害的還是，functiont提供一種能力：對于function＜double(int)＞類型的泛型函數(shù)指針，用戶可以給它一個int(int)類型的函數(shù)——是的，這是可行且安全的，因為其返回值類型int可以安全的轉(zhuǎn)型為double，而對于這種類型兼容性的檢查就在上面分析的invoke靜態(tài)成員函數(shù)中，這就是我們要說的額外好處——假如類型兼容，那么invoke函數(shù)就能正常編譯通過，但假如用戶給出類型不兼容的函數(shù)，就會得到一個錯誤，這個錯誤是在編譯器實例化invoke函數(shù)代碼的時候給出的，例如，用戶假如這樣寫：

RT1 f(P1,P2); // RT1(P1,P2)函數(shù)類型，這里的RT1,P1,P2假定已經(jīng)定義，這是一般化的符號

function＜RT(P)＞ f_ptr; //RT(P)函數(shù)類型，同樣假定RT,P已定義

f_ptr = &f; //類型不兼容，錯誤！
　　這就會導致編譯錯誤，錯誤發(fā)生在invoke靜態(tài)成員函數(shù)中。下面我就為你解釋為什么。

　　我想你對function_invoker1考的三個模板參數(shù)仍然心存迷惑，我們再一次往返顧一下其聲明：

template＜typename FunctionPtr,typename R，typename T0＞

struct function_invoker1
　　我們還得把目光投向assign_to模板函數(shù)，其中使用function_invoker1的時候是這樣的：

typedef typename detail::function::get_function_invoker1＜

FunctionPtr,R,T0＞::type invoker_type;
　　這里，給出的FunctionPtr,R,T0三個模板參數(shù)將會原封不動的傳給function_invoker1，那么對于我們上面的錯誤示例，這三個模板參數(shù)各是什么呢？

　　首先，我們很輕易看出，F(xiàn)unctionPtr就是assign_to模板函數(shù)的模板參數(shù)，也就是用戶傳遞的函數(shù)或仿函數(shù)的類型，在我們的錯誤示例中，函數(shù)f的類型為RT1(P1,P2)，所以

FunctionPtr = RT1(*)(P1,P2)
　　而R,T0則是用戶在實例化function模板時給出的模板參數(shù)，我們寫的是function＜RT(P)＞，于是:

R = RT

T0 = P
　　所以，對于我們的錯誤示例，invoker_type的類型為：

function_invoker1＜ RT1(*)(P1,P2),RT,P＞
　　對于這樣一個function_invoker1，其內(nèi)部的invoke靜態(tài)成員函數(shù)被實例化為：

static RT invoke(any_pointer function_ptr,P a0)
{
　RT1 (*f)(P1,P2)= //FunctorPtr f =reinterpret_cast＜RT1(*)(P1,P2)＞(function_ptr.func_ptr);
　return f(a0); //錯啦！瞧瞧f的型別，f接受一個P類型的參數(shù)嗎？編譯器在此打住。
　//這行語句的另一個隱含的檢查是返回值類型匹配，f(...)返回RT1，而invoke須得返回RT
}
　　看看最后一行語句，所有的檢查都在那里了——我們最終把檢查“委托”給了C++底層的類型系統(tǒng)。

　　很精妙不是嗎？雖然在模板形式的assign_to函數(shù)中，看起來我們并不關(guān)心到底用戶給的參數(shù)是何類型，看起來用戶可以把任何函數(shù)或仿函數(shù)塞過來，但是一旦下面觸及invoker的賦值，就得實例化invoke靜態(tài)成員函數(shù)，其中的：

return f(a0);
　　一下就把問題暴露出來了！這種把類型檢查延遲到最后，不得不進行的時候，由C++底層的類型系統(tǒng)來負責檢查的手法的確很奇妙——看起來我們沒有在assign_to函數(shù)中及時利用類型信息進行類型檢查，但是我們卻并沒有喪失任何類型安全性，一切最終都逃不過C++底層的類型系統(tǒng)的考驗！

　　function如何對待成員函數(shù)

　　對于成員函數(shù)，assign_to的重載版本只有一行：

this-＞assign_to(mem_fn(f));
　　mem_fun(f)返回一個仿函數(shù)，它封裝了成員函數(shù)f，之后一切皆與仿函數(shù)無異。

　　關(guān)于mem_fun的細節(jié)，這里就不多說了，大家可以參考STL中的實現(xiàn)，相信很輕易看懂，這里只簡單的提醒一下，成員函數(shù)封裝的效果是這樣的：

R (C::*)(T0,T1,...) --＞ R (*)(C*,T0,T1,...) 或 R (*)(C&,T0,T1,...)
　　safe_bool慣用手法

　　如你所知，對于函數(shù)指針fptr，我們可以這樣測試它：if(fptr) ...，所以function也應該提供這一特性，然而假如直接重載operator 　bool()則會導致下面的代碼成為合法的:

function＜int(int)＞ f;

bool b=f;
　　這顯然不妥，所以function用另一個巧妙的手法替代它，既所謂的safe_bool慣用手法，這在function定義內(nèi)部的源碼如下：

struct dummy { void nonnull(){};};

typedef void (dummy::*safe_bool)(); //確保safebool不能轉(zhuǎn)型為任何其它類型！

operator safe_bool () const

{ return (this-＞empty())? 0 : &dummy::nonnull; }
　　這樣，當你寫if(f)的時候，編譯器會找到operator safe_bool()，從而將f轉(zhuǎn)型為safe_bool，這是個指針類型，if語句會正確判定它是否為空。而當你試圖把f賦給其它類型的變量的時候則會遭到編譯期的拒絕——因為safe_bool無法向其它類型轉(zhuǎn)換。

get_function_tag＜＞
　　get_function_tag＜＞用于萃取出函數(shù)所屬類別(category)，各個類別在源代碼中已經(jīng)列出，至于它到底是如何萃取的，這與本文關(guān)系不是很　大，有一點需要提醒一下：函數(shù)指針類型也是指針類型，這聽起來完全是句廢話，但是考慮這樣的代碼：

template＜typename T＞ struct is_pointer{enum{value=0};};

template＜typename T＞ struct is_pointer＜T*＞{enum{value=1};};

std::cout＜＜is_pointer＜int(*)(int)＞::value; //這將輸出 1
　　也就是說int(*)(int)可以與T*形式匹配，匹配時T為int(int)。

　　最后一些細節(jié)

　　1. 我沒有給出function_base的源代碼，實際上那很簡單，它最主要的成員就是union any_pointer型的數(shù)據(jù)成員

detail::function::any_pointer functor; //用于統(tǒng)一保存函數(shù)指針及仿函數(shù)對象指針
　　2. 我沒有給出functor_manager的信息，實際上它與function的實現(xiàn)沒有太大關(guān)系，它負責copy和delete函數(shù)對象，假如必要的話。所以我將它略去，它的源碼在：”boost/function/function_base.hpp”里。

　　3. 我給出的源代碼是將宏展開后的版本，實際的代碼中充斥著讓人眼花繚亂的宏，關(guān)于那些宏則又是一個奇妙的世界。Boost庫通過那些宏省去了許多可見代碼量。隨著函數(shù)參數(shù)的不同，那些宏會擴展出function2,function3...各個版本。

　　本文只研究了int(int)型的情況，其它只是參數(shù)數(shù)目的改變而已。經(jīng)過宏的擴展，function的偏特化版本將有:

template＜typename R,typename Allocator＞

class function＜R(),Allocator＞:public function0＜R,Allocator＞

{...};

template＜typename R,typename T0,typename Allocator＞

class function＜R(T0),Allocator＞:public function1＜R,T0,Allocator＞

{...};

template＜typename R,typename T0,typename T1,typename Allocator＞

class function＜R(T0,T1),Allocator＞:public function2＜R,T0,T1,Allocator＞

{...};

　　等更多版本，一共有BOOST_FUNCTION_MAX_ARGS+1個版本，BOOST_FUNCTION_MAX_ARGS為一個宏，表示最多能夠接受有多少個參數(shù)的函數(shù)及仿函數(shù)對象，你可以重新定義這個宏為一個新值，以控制function所能支持的函數(shù)參數(shù)個數(shù)的最大值。其中的function0,function1,function2等名字也由宏擴展出。

更多內(nèi)容請看C/C++技術(shù)專題專題，或

上一篇：C++ 中園形三角形按鈕的實現(xiàn)

下一篇：C++中用函數(shù)模板實現(xiàn)和優(yōu)化抽象操作