boost源碼剖析之：泛型函數指針類boost::function

boost源碼剖析之：泛型函數指針類boost::function(rev#3)

劉未鵬

C++的羅浮宮(http://blog.csdn.net/pongba)

Note: 并非新作，03年曾放在blog上，現在這個版本應該是修改後的最終版本。

前奏

如你所知，boost庫是個特性完備，且具備工業強度的庫，衆多C++權威的參與使其達到了登峰造極的程度。尤其泛型的強大威力在其中被發揮得淋漓盡緻，令人瞠目結舌。

然而弱水三千，我們隻取一瓢飲。下面，我試圖從最單純的世界開始，一步一步帶領你進入源碼的世界，去探究boost::function(下文簡稱function)内部的精微結構。

通常 ，在單純的情況下，對函數的調用簡單而且直覺，像這樣：

int fun(int someVal);

  int main(){

    fun(10);

  }

然而你可能需要在某個時刻将函數指針儲存下來，并在以後的另一個時刻調用它，像這樣：

  int fun(int);

  typedef int (*func_handle)(int);

  int main(){

    func_handle fh=fun;

    ...  //do something

    fh(10);

  }

但是，如果fun形式為void fun(int)呢？如你所見，fun可能有無數種形式，如果對fun的每一個形式都typedef一個對應的func_handle，則程式員會焦頭爛額，不勝其擾，代碼也可能變得臃腫和醜陋不堪，甚至如果fun是仿函數呢？

幸運的是C++泛型可以使代碼變得優雅精緻，面對無數種的可能，泛型是最好的選擇。

是以，你隻是需要一個能夠儲存函數指針的泛型模闆類(對應于Command模式)，因為泛型程式設計有一個先天性的優勢——可以借助編譯器的力量在編譯期根據使用者提供的類型資訊化身千萬(執行個體化)，是以一個泛型的類可以有無限個執行個體，也就是說可以儲存無限多種可能類型的函數或類似函數的東西(如仿函數)。這個類(在boost庫中的類名為function)與函數指針相比應該有以下一些優勢：

1. 同一個function對象應能夠接受與它形式相容的所有函數和仿函數,例如：

int f1(int); // 這是個函數，形式為 int(int)

short f2(double); // 這個函數形式為 short(double)

  struct functor // 這是個仿函數類，形式為int(int)

  {

    int operator()(int){}

  };

functor f3; //建立仿函數對象

boost::function<int(int)> func; // 能接受int(int)型的函數或仿函數

func = f1;  // 接受f1

func(10); // 調用f1(10)

func = f2;  // 也能接受short(double)型的f2

func(10); // 調用f2(10)

func = f3;  // 也能接受仿函數f3

func(10); // 調用f3(10)

2. function應能夠和參數綁定以及其它function-construction庫協同工作。例如，function應該也能夠接受std::bind1st傳回的仿函數。這一點其實由第一點已經有所保證。

3. 當接受的一個空的仿函數對象被調用的時候function應該有可預期的行為。

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

R1 (T0,T1,T2,...,TN) => FunctionType1

R2 (P0,P1,P2,...,PN) => FunctionType2

兩種類型的函數（廣義），隻要滿足：

R2能夠隐式轉換為R1

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

那麼就說，boost::function<FunctionType1>可以接受FunctionType2類型的函數(注意，反之不行)。支援這一論斷的理由是，隻要Ti能夠隐式轉型為Pi，那麼參數被轉發給真實的函數調用就是安全的，并且如果R2能夠隐式轉型為R1，那麼傳回真實函數調用所傳回的值就是安全的。這裡安全的含義是，C++類型系統假定隐式轉換不會丢失資訊，或者編譯器至少會給出編譯警告。

後面你會看到，boost::function通過所謂的invoker非常巧妙地實作了這點，并且阻止了被形式不相容的函數指派的操作。

探險

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

int g(int); // 為了讓代碼簡單，假設g有定義，以後的代碼都會如此

function<int(int)> f(g);

f(0);

間奏——R(T1,T2,...)函數類型

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

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

template<class T>

void test_func_type(T ft) // 按值傳遞，類型退化

{

// 故意引發編譯錯誤，在錯誤資訊裡看出ft的類型為退化後的函數指針類型

static_cast<int>(ft);

}

int g(int); // g的确切類型為int(int)

test_func_type(g);  // g的類型将會退化為函數指針類型

int (&ref_f)(int) = g; // 由于綁定到引用，類型并不退化

當然，這樣的代碼不能通過編譯，因為static_cast顯然不會讓一個函數指針轉換為int，然而我們就是要它通不過編譯，這樣我們才能窺視到按值傳遞的參數ft的類型到底是什麼，從編譯錯誤中我們看出，ft的類型是int(*)(int)，也就是說，在按值傳遞的過程中，g的類型退化為函數指針類型，變得和&g的類型一樣了。而ref_t的類型則是引用，引用綁定則沒有引起類型退化。

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

繼續旅程

function<int(int)>實際上進行了模闆偏特化，boost庫給function的類聲明為：

template<

typename Signature,  //函數類型

typename Allocator = ... //Allocator并非重點，故不作介紹

> 

class function;

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

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

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

template<typename R,typename T0,typename Allocator>

class function<R(T0),Allocator> // 對R(T0)函數類型的偏特化版本

:public function1<R,T0,Allocator> // 為R(T0)形式的函數準備的基類

{

typedef function1<R,T0,Allocator> base_type;

typedef function selftype;

struct clear_type{}; // 馬上你會看到這個蹊跷的類型定義的作用

public:

…

// 模闆化的構造函數，為了能夠接受形式相容的仿函數對象。

// 這個構造函數的作用在下面解釋

template<typename Functor>

  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() {}

...

};

boost::enable_if

你一定對模闆構造函數中出現的那個冗長的enable_if<...>的作用心存疑惑，其實它的作用說穿了很簡單，就是：當使用者構造：

function<int(int)> f(0);

的時候，将該（帶有enable_if的）構造函數從重載決議的候選集中踢掉。使重載決議的結果為選中第三個構造函數：

function(clear_type*):base_type(){}

進而進行預設構造。

而說得冗長一點就是：當f的類型——Functor——不是int時，該構造函數就是“有效（enable）”的，會被重載決議選中。但如果使用者提供了一個0，用意是構造一個空(null)的函數指針，那麼該函數就會由于“SFINAE”原則而被從重載決議的候選函數中踢掉。為什麼要這樣呢？因為該構造函數負責把确切的f儲存起來，它假定f并非0。那應該選擇誰呢？第三個構造函數！其參數類型是clear_type*，當然，0可以被賦給任何指針，是以它被選出，執行預設的構造行為。

基類 functionN

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

不知道你有沒有發現，function的骨架中也幾乎沒有用到函數類型的資訊，事實上，它也将這些資訊一股腦兒抛給了基類。在這過程中，混沌一團的int(int)類型被拆解為兩個單獨的模闆參數傳給基類:

template<typename R,typename T0,typename Allocator>

class function<R(T0),Allocator> // R(T0)整個為一類型

:public function1<R,T0,Allocator> // 拆解為兩個模闆參數R,T0傳給基類

好了，下面我們深入基類function1。真正豐富的寶藏在裡面。

function1

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

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

template<typename R,typename T0,class Allocator = ...>

class function1

: public function_base // function_base負責管理記憶體

{

...

public:

typedef R result_type;   //傳回類型

typedef function1 self_type;

template<typename Functor>

function1(Functor const & f,

typename enable_if<...>::type = 0)

: function_base(), invoker(0)

{

this->assign_to(f);   //這兒真正進行指派，assign_to的代碼在下面列出

}

template<typename Functor>

void assign_to(Functor f) // 所有的構造函數都調用它！具有多個重載版本。

{

     // 以一個get_function_tag萃取出Functor的類别(category)!

typedef typename detail::function::get_function_tag<Functor>::type

tag;

      // 根據不同類别的Functor采取不同的assign政策！

this->assign_to(f, tag()); // 轉到真正做事情的assign_to版本，見下文。

}

...

result_type operator()(T0 a0) const // 身為仿函數的标志！

{

...

    // 這裡進行真正的函數調用，使用invoker，

// invoker是functionN的成員變量，在下面的assign_to中被指派。

// functor為實際被調用的函數或仿函數，a0當然是其參數。

    internal_result_type result = invoker(function_base::functor, a0);

// 将得到的結果cast至最終傳回出去的類型

return static_cast<result_type>(result);

}

其中值得注意的是：

get_function_tag<>能萃取出Functor的類别(category)，有下面幾種類别

struct function_ptr_tag {}; // 函數指針

struct function_obj_tag {}; // 仿函數對象

struct member_ptr_tag {}; // 成員函數

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

struct stateless_function_obj_tag {}; // 無狀态函數對象

此外，滿足以下所有條件：

has_trivial_constructor

has_trivial_copy

has_trivial_destructor

is_empty

的仿函數對象稱為stateless的。

對于不同的函數類别，assign_to有各個不同的重載版本，如下：

template<typename FunctionPtr> // 如果是函數指針就調用這個版本

void assign_to(FunctionPtr f, function_ptr_tag) // 這個版本針對函數指針

{

clear();

  if(f){

    typedef

typename ...::get_function_invoker1<

                  FunctionPtr,R,T0>::type

invoker_type; // 萃取相應的invoker

invoker = &invoker_type::invoke; // invoke是一個static成員函數

function_base::manager = // 管理政策，一個函數指針

      &...::functor_manager<FunctionPtr, Allocator>::manage;

// 交給function的函數指針或仿函數對象指針最終在這兒儲存

function_base::functor =

function_base::manager(

...::make_any_pointer((void (*)())(f)),

        ...::clone_functor_tag); // 拷貝一份

}

}

  ...

  // any_pointer在下文解釋

typedef internal_result_type(*invoker_type)(...::any_pointer, T0);

invoker_type invoker; // 重要成員，負責調用函數！

}; // function1類定義的結尾

function的底層存儲機制

請将目光轉向上面的代碼段末尾的assign_to函數中，其中有兩行代碼分别對function_base裡的manager和functor成員指派。這兩行代碼肩負了儲存各種函數指針的任務。

manager是一個函數指針，它所指向的函數代表管理政策，例如，對于函數指針，僅僅作一次指派，就儲存完畢了，但是對于仿函數，得額外配置設定一次記憶體，然後将仿函數拷貝到配置設定的記憶體中，這才完成了儲存的任務。這些政策根據函數的類别而定，上面代碼中的assign_to函數是針對函數指針類别的重載版本，是以manager的政策是不作任何記憶體配置設定，直接傳回被轉型為“void(*)()”（利于在底層以統一的形式儲存）的函數指針就行了，這從代碼中可以看出。

需要說明的是，對于函數指針，function_base并不知道也不關心它要儲存的函數指針是什麼确切的類型，隻要是函數指針就行，因為它總會把該函數指針f轉型為“void (*)()”類型，然後儲存在functor成員中，functor成員是一個union類型:

union any_pointer

{

    // 任意仿函數對象指針都可以用static_cast轉型為void*型

void* obj_ptr;

    // 為const仿函數準備的

const void* const_obj_ptr;

// 任意函數指針都可以用reinterpret_cast轉型為void(*)()型

void (*func_ptr)();

char data[1];

};

這個any_pointer可以通過安全轉型儲存所有形式的仿函數和函數指針，承載在底層儲存資料的任務

function的調用機制——invoker

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

typedef internal_result_type (*invoker_type)(any_pointer,T0);

前面已經說過，any_pointer是個union，可以儲存任何類型的函數指針或函數對象，裡面儲存的是使用者給出的函數或仿函數，T0則是儲存于any_pointer中的函數的參數類型（若有兩個參數則是T1,T2）。這也就是說，invoker負責調用儲存在any_pointer中的函數或仿函數。

那麼，invoker這個函數指針到底指向什麼函數呢——也就是說，在什麼時候invoker被指派了呢？我們再次把目光轉向assign_to函數，其中有一行對invoker成員指派的語句，從這行語句出發我們可以揭開invoker的全部奧秘：

invoker = &invoker_type::invoke; // invoke是一個static成員函數

請不要把這個invoker_type和上面那個函數指針類型invoker_type混淆起來，這個invoker_type是位于assign_to函數中的一個局部的typedef，是以隐藏了後者（即類作用域中的那個invoker_type——invoker成員的類型）。往上一行，你就看到這個局部類型invoker_type的定義了：

typedef typename get_function_invoker1<

          FunctionPtr,R,T0>::type invoker_type;

get_function_invoker1又是何物？很顯然，這是個traits，其内嵌的::type會根據不同的模闆參數表現為不同的類型，在本例中，::type的類型将會被推導為

function_invoker1<int(*)(int),int,int>

而function_invoker1是個類模闆，其定義為：

template<

typename FunctionPtr,

typename R，typename T0

> // 注意這裡的模闆參數，後面會解釋

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的定義可以看出，

function_invoker1<int(*)(int),int,int>::invoke是一個靜态成員函數，它被執行個體化後相當于：

static int invoke(any_pointer function_ptr, int a0)

{

// 先轉型，再調用，注意，這一行語句還有一個額外的作用，在後面解釋

int (*f)(int) = reinterpret_cast<int(*)(int)>(function_ptr.func_ptr);

// 因為f指向的是使用者儲存在該function中的函數或仿函數，

// 是以這一行語句進行了最終真正的調用！

return f(a0);

}

我們可以看出，在invoke函數中，真正的調用現身了。

此外，如果使用者當初給出的是仿函數而不是函數指針，則有function_obj_invoker1與它對應，後者也是一個類似的模闆，它的invoke靜态成員函數的形式也是：

static R invoke(any_pointer function_obj_ptr, T0 a0);

其中function_obj_ptr是指向仿函數的指針，是以這個版本的invoke中對它的調用語句是這樣的：

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

return (*f)(a0); // 調用使用者當初給出的仿函數

最後一種可能：如果接受的是成員函數怎麼辦呢？簡單的答案是：boost::function并沒有為成員函數作任何特殊準備！理由也很簡單，boost::function隻要先将成員函數封裝為仿函數，然後将其作為一般的仿函數對待就行了，具體代碼就不列了，STL中有一個函數模闆std::mem_fun就是用于封裝成員函數指針的，它傳回的是一個仿函數。boost中也對該函數模闆做了擴充，使它可以對付任意多個參數的成員函數。

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

我們注意到function的構造和指派函數及其基類的構造和指派函數都是模闆函數，這是因為使用者可能提供函數也可能提供仿函數，但最關鍵的還是，functiont提供一種能力：對于function<double(int)>類型的泛型函數指針，使用者可以給它一個int(int)類型的函數——是的，這是可行且安全的，因為其傳回值類型int可以安全的轉型為double，而對于這種類型相容性的檢查就在上面分析的invoke靜态成員函數中，這就是我們要說的額外好處——如果類型相容，那麼invoke函數就能正常編譯通過，但如果使用者給出類型不相容的函數，就會得到一個錯誤，這個錯誤是在編譯器執行個體化invoke函數代碼的時候給出的，例如，使用者如果這樣寫：

// 聲明一個雙參的函數f

RT1 f(P1,P2);

  // 單參的function執行個體

function<RT(P)> f_ptr;

f_ptr = &f; // 類型不相容，錯誤！

這就會導緻編譯錯誤，錯誤發生在invoke靜态成員函數中。下面我就為你解釋為什麼。

我想你對function_invoker1的三個模闆參數仍然心存疑惑，我們再一次來回顧一下其聲明：

template<

typename FunctionPtr,

typename R，typename T0>

struct function_invoker1

我們還得把目光投向assign_to模闆函數，其中使用function_invoker1的時候是這樣的：

typedef typename ...::get_function_invoker1<

                         FunctionPtr,R,T0>::type invoker_type;

FunctionPtr，R，T0三個模闆參數将會被原封不動的傳給function_invoker1，那麼對于我們上面的錯誤示例，這三個模闆參數各是什麼呢？

首先，我們很容易看出，FunctionPtr就是assign_to模闆函數的模闆參數，也就是使用者傳遞的函數或仿函數的類型，在我們的錯誤示例中，函數f的類型為RT1(P1,P2)，是以

FunctionPtr = RT1(*)(P1,P2)

而R,T0則是使用者在執行個體化function模闆時給出的模闆參數，我們寫的是function<RT(P)>，于是:

R = RT

T0 = P

是以，對于我們的錯誤示例，invoker_type的類型為：

function_invoker1< RT1(*)(P1,P2),RT,P>

對于這樣一個function_invoker1，其内部的invoke靜态成員函數被執行個體化為：

static RT invoke(any_pointer function_ptr,P a0)

{

  // 注意f的類型

RT1 (*f)(P1,P2) = reinterpret_cast<RT1(*)(P1,P2)>(function_ptr.func_ptr);

return f(a0); //錯啦！瞧瞧f的類型，f能接受一個P類型的參數嗎？編譯器在此打住。

}

看看最後一行語句，所有的檢查都在那裡了——我們最終把檢查“委托”給了C++底層的類型系統。

很精妙不是嗎？雖然在模闆形式的assign_to函數中，看起來我們并不關心到底使用者給的參數是何類型，看起來使用者可以把任何函數或仿函數塞過來，但是一旦下面觸及invoker的指派，就得執行個體化invoke靜态成員函數，其中的：

return f(a0);

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

function如何對待成員函數

對于成員函數，assign_to的重載版本隻有一行：

this->assign_to(mem_fn(f));

mem_fun(f)傳回一個仿函數，它封裝了成員函數f，之後一切皆與仿函數無異。

關于mem_fun的細節，這裡就不多說了，大家可以參考STL中的實作，相信很容易看懂，這裡隻簡單的提醒一下，成員函數封裝的效果是這樣的：

R (C::*)(T0,T1,...) => R (*)(C*,T0,T1,...) 或 R (*)(C&,T0,T1,...)

safe_bool慣用手法

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

function<int(int)> f;

int b=f;

這顯然不妥，是以function用另一個巧妙的手法替代它，既所謂的safe_bool慣用手法，這在function定義内部的源碼如下：

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

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

operator safe_bool () const

{ return (this->empty())? 0 : &dummy::nonnull; }

這樣，當你寫if(f)的時候，編譯器會找到operator safe_bool()，進而将f轉型為safe_bool，這是個指針類型，if語句會正确判定它是否為空指針。而當你試圖把f賦給其它整型變量的時候則會遭到編譯期的拒絕——因為safe_bool是一個成員指針類型，無法向其它整型轉換。

get_function_tag

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

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)。

最後一些細節

1. 我沒有給出function_base的源代碼，實際上那很簡單，它最主要的成員就是一個union any_pointer型的資料成員

    // 用于統一儲存函數指針及仿函數對象指針

detail::function::any_pointer functor; 

2. 我沒有給出functor_manager的資訊，實際上它與function的實作沒有太大關系，它負責copy和delete函數對象，如果必要的話。是以我将它略去，它的源碼在”boost/function/function_base.hpp”裡。

3. 我給出的源代碼是将宏展開後的版本，實際的代碼中充斥着讓人眼花缭亂的宏，關于那些宏則又是一個奇妙的世界。boost庫通過那些宏省去了許多可見代碼量。随着函數參數的不同，那些宏會擴充出function2,function3...各個版本。而本文隻研究了int(int)型的情況，其它隻是參數數目的改變而已。經過宏的擴充，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為一個宏，控制最多能夠接受有多少個參數的函數及仿函數對象，你可以重新定義這個宏為一個新值，以控制function所能支援的函數參數個數的最大值。其中的function0,function1,function2等名字也由宏擴充出。