青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

小步慢跑

 

<轉(zhuǎn)>Boost源碼剖析之:泛型函數(shù)指針類boost::function(修訂版)

   原作者:劉未鵬  

2003年9月發(fā)表于《程序員》,本文較之有極大改動,特別在中后部分:-)   

前奏 

如你所知,Boost庫是個特性完備,且具備工業(yè)強(qiáng)度的庫,眾多C++權(quán)威的參與使其達(dá)到了登峰造極的程度。尤其泛型的強(qiáng)大威力在其中被發(fā)揮得淋漓盡致,令人瞠目結(jié)舌。 然而弱水三千,我們只取一瓢飲。下面,我試圖從最單純的世界開始,一步一步帶領(lǐng)你進(jìn)入源碼的世界,去探究boost::function(下文簡稱function)內(nèi)部的精微結(jié)構(gòu)。通常 ,在單純的情況下,對函數(shù)的調(diào)用簡單而且直觀,像這樣:   

   1:   int fun(int someVal);
   2:    int main(){
   3:    fun(10);
   4:    }

  然而你可能需要在某個時刻將函數(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)呢?如你所見,fun可能有無數(shù)種形式,如果對fun的每一個形式都typedef一個對應(yīng)的func_handle,則程序員會焦頭爛額,不勝其擾,代碼也可能變得臃腫和丑陋不堪,甚至如果fun是仿函數(shù)呢?   幸運(yùn)的是C++泛型可以使代碼變得優(yōu)雅精致,面對無數(shù)種的可能,泛型是最好的選擇?! ?因此,你只是需要一個能夠保存函數(shù)指針的泛型模板類(對應(yīng)于Command模式),因為泛型編程有一個先天性的優(yōu)勢——可以借助編譯器的力量在編譯期根據(jù)用戶提供的型別信息化身千萬(具現(xiàn)化),所以一個泛型的類可以有無限個具現(xiàn)體,也就是說可以保存無限多種可能型別的函數(shù)或類似函數(shù)的東西(如,仿函數(shù))。這個類(在Boost庫中的類名為function)與函數(shù)指針相比應(yīng)該有以下一些優(yōu)勢:  

  • 同一個function對象應(yīng)能夠接受與它形式兼容的所有函數(shù)和仿函數(shù),例如:    
       1: int f1(int); //這是個函數(shù),形式為 int(int) 
       2: short f2(double); //這個函數(shù)形式為 short(double)    
       3: struct functor //這是個仿函數(shù)類,形式為int(int)    
       4: {    
       5:     int operator()(int){}    
       6: };    
       7: functor f3; //創(chuàng)建仿函數(shù)對象  
       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庫協(xié)同工作。例如,function應(yīng)該也能夠接受std::bind1st返回的仿函數(shù)。這一點(diǎn)其實(shí)由第一點(diǎn)已經(jīng)有所保證?! ?
  • 當(dāng)接受的一個空的仿函數(shù)對象被調(diào)用的時候function應(yīng)該有可預(yù)期的行為?! ?/li>

     顯然,第一點(diǎn)是我們的重點(diǎn),所謂形式兼容,就是說,對于:  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可以接受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)換不會丟失信息,或者會給出編譯警告,但能夠通過編譯。  后面你會看到,boost::function通過所謂的invoker非常巧妙地實(shí)現(xiàn)了這點(diǎn),并且阻止了被形式不兼容的函數(shù)賦值的操作。  

探險

        好吧,準(zhǔn)備好,我們要出發(fā)了,進(jìn)行深入源碼世界的探險。先看一個function的最簡單的使用:    

   1: int g(int); //為了讓代碼簡單,假設(shè)g有定義,以后的代碼都會如此   
   2: unction f(g);    
   3: f(0);  

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

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

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

   1: template void test_func_type(T ft) //按值傳遞,類型退化   
   2: {    
   3:     static_cast(ft); //引發(fā)編譯錯誤,從而看出ft的類型為退化后的函數(shù)指針   
   4: }    
   5:  
   6: int g(int); //函數(shù)g,名字g的類型為int(int)
   7: test_func_type(g); //注意,并非&g,參數(shù)g的類型將會退化為函數(shù)指針類型   
   8: int (&ref_f)(int) = g; //注意,并非“= &g”,因為綁定到引用,類型并不退化  

當(dāng)然,這樣的代碼不能通過編譯,因為static_cast<>顯然不會讓一個函數(shù)指針轉(zhuǎn)換為int,然而我們就是要它通不過編譯,這樣我們才能窺視到按值傳遞的參數(shù)ft的類型到底是什么,從編譯錯誤中我們看出,ft的類型是int(*)(int),也就是說,在按值傳遞的過程中,g的類型退化為函數(shù)指針類型,變得和&g的類型一樣了。而ref_t的類型則是引用,引用綁定則沒有引起類型退化。  請注意,函數(shù)類型乃是個極其特殊的類型,在大多數(shù)時候它都會退化為函數(shù)指針類型,以便滿足拷貝語義,只有面對引用綁定的時候,能夠維持原來的類型。當(dāng)然,對于boost::function,總是按值拷貝?! ?/p>

繼續(xù)旅程 

       好吧,回過神來,我們還有更多地帶要去探究?! ?/p>

       function實(shí)際上進(jìn)行了模板偏特化,Boost庫給function的類聲明為:

   1: template<typename Signature, //函數(shù)類型
   2:  typename Allocator = ...
   3:  > //Allocator并非重點(diǎn),故不作介紹
   4:  class function;

 事實(shí)上function類只是個薄薄的外覆(wrapper),真正起作用的是偏特化版本?! τ趂unction形式,偏特化版本的function源碼像這樣(實(shí)際上在boost源代碼中你看不到模板參數(shù)T0的聲明,也看不到function1,它們被宏替換掉了,那些精巧的宏是為了減小可見的代碼量,至于它們的細(xì)節(jié)則又是一個世界,以下代碼可看作對將那些令人眼花繚亂的宏展開后所得到的代碼,具有更好的可讀性): 

   1:   //摘自:”boost/function/function_template.hpp”
   2: template<typename R,typename T0,typename Allocator>
   3:   class function<R(T0),Allocator> //對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{}; //馬上你會看到這個蹊蹺的類型定義的作用
   9:  
  10:   public:
  11:       function() : base_type() {} //默認(rèn)構(gòu)造
  12:       template<typename Functor> //模板化的構(gòu)造函數(shù),為了能夠接受形式兼容的仿函數(shù)對象
  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òu)造函數(shù)的作用在下面解釋
  19:       self_type& operator=(const self_type& f) //同類型function對象之間應(yīng)該能夠賦值
  20:       {
  21:           self_type(f).swap(*this); //swap技巧,細(xì)節(jié)見《Effective STL》
  22:           return *this;
  23:       }
  24:       ...
  25:   };
  26:   enable_if

你一定對模板構(gòu)造函數(shù)中出現(xiàn)的那個冗長的enable_if<...>的作用心存疑惑,其實(shí)它的作用說穿了很簡單,就是:當(dāng)用戶構(gòu)造:

  function f(0);

  的時候,將該(帶有enable_if的)構(gòu)造函數(shù)從重載決議的候選集中踢掉。使重載決議的結(jié)果為選中第三個構(gòu)造函數(shù):

  function(clear_type*):base_type(){}

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

 基類 functionN

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

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

   1: template<typename R,typename T0,typename Allocator>
   2:   class function<R(T0),Allocator> //R(T0)整個為一型別
   3:   :public function1<R,T0,Allocator> //拆解為兩個模板參數(shù)R,T0傳給基類

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

function1

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

   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ù)上面解釋過
  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)用它!具有多個重載版本。
  35:    {
  36:    //以一個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ù)對象類別
  43:   struct member_ptr_tag {}; //成員函數(shù)類別
  44:   struct function_obj_ref_tag {};//以ref(obj)加以封裝的類別,具有引用語義
  45:   struct stateless_function_obj_tag {}; //無狀態(tài)函數(shù)對象
  46:   滿足以下所有條件:
  47:   has_trivial_constructor
  48:   has_trivial_copy
  49:   has_trivial_destructor
  50:   is_empty
  51:   的仿函數(shù)對象稱為stateless的
  52:   而對于不同的函數(shù)類別,assign_to有各個不同的重載版本,如下:
  53:   template<typename FunctionPtr> //如果是函數(shù)指針就調(diào)用這個版本
  54:   ? void assign_to(FunctionPtr f, function_ptr_tag) //這個版本針對函數(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ù)對象指針最終在這兒保存
  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)被這段“夾敘夾議”的代碼弄得頭昏腦漲了,但這才剛剛開始!  

function的底層存儲機(jī)制  

      請將目光轉(zhuǎn)向上面的代碼段末尾的assign_to函數(shù)中,其中有兩行深色的代碼,分別對function_base里的manager和functor成員賦值。這兩行代碼肩負(fù)了保存各種函數(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:

   1: union any_pointer
   2: {
   3:    void* obj_ptr; //任意仿函數(shù)對象指針都可以用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: };   

這個any_pointer可以通過安全轉(zhuǎn)型保存所有形式的仿函數(shù)和函數(shù)指針,承載在底層保存數(shù)據(jù)的任務(wù)  

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

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

   1: 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負(fù)責(zé)調(diào)用保存在any_pointer中的用戶提供的函數(shù)或仿函數(shù)。  那么,invoker這個函數(shù)指針到底指向什么函數(shù)呢——也就是說,在什么時候invoker被賦值了呢?我們再次把目光轉(zhuǎn)向assign_to函數(shù),其中有一行對invoker成員賦值的語句,從這行語句出發(fā)我們可以揭露invoker的全部奧秘:    

   1: invoker = &invoker_type::invoke; //invoke是static成員函數(shù)

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

    

   1: typedef typename get_function_invoker1<FunctionPtr,R,T0>::type invoker_type;

 get_function_invoker1又是何物?很顯然,這是個traits,其內(nèi)嵌的::type會根據(jù)不同的模板參數(shù)表現(xiàn)為不同的類型,在本例中,::type的類型將會被推導(dǎo)為  function_invoker1   而function_invoker1是個類模板,其定義為: 

   1: template<typename FunctionPtr,
   2:  typename R,typename T0> //注意這里的模板參數(shù),后面會解釋
   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:   };

所以對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)用,注意,這一行語句還有一個額外的作用,在后面解釋
   4:  int (*f)(int) = reinterpret_cast(function_ptr.func_ptr);    
   5: //因為f指向的是用戶保存在該function中的函數(shù)或仿函數(shù),所以這一行語句進(jìn)行了真實(shí)的調(diào)用!
   6:  return f(a0);
   7: }

 

  我們可以看出,在invoke函數(shù)中,真正的調(diào)用現(xiàn)身了。

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

   static R invoke(any_pointer function_obj_ptr,T0 a0);

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

   1:   FunctionObj* f = (FunctionObj*)(function_obj_ptr.obj_ptr);
   2:   return (*f)(a0); //調(diào)用用戶的仿函數(shù)

 

  最后一種可能:如果接受的是成員函數(shù)怎么辦呢?簡單的答案是:boost::function并沒有為成員函數(shù)作任何特殊準(zhǔn)備!理由也很簡單,boost::function只要先將成員函數(shù)封裝為仿函數(shù),然后將其作為一般的仿函數(shù)對待就行了,具體代碼就不列了,STL中有一個函數(shù)模板std::mem_fun就是用于封裝成員函數(shù)指針的,它返回的是一個仿函數(shù)。boost中也對該函數(shù)模板做了擴(kuò)充,使它可以接受任意多個參數(shù)的成員函數(shù)。

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

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

   1:    RT1 f(P1,P2); // RT1(P1,P2)函數(shù)類型,這里的RT1,P1,P2假定已經(jīng)定義,這是一般化的符號
   2:    function f_ptr; 
   3:     //RT(P)函數(shù)類型,同樣假定RT,P已定義
   4:     f_ptr = &f; //類型不兼容,錯誤!

 

  這就會導(dǎo)致編譯錯誤,錯誤發(fā)生在invoke靜態(tài)成員函數(shù)中。下面我就為你解釋為什么。

  我想你對function_invoker1考的三個模板參數(shù)仍然心存疑惑,我們再一次來回顧一下其聲明:

   1: template<typename FunctionPtr,typename R,typename T0>  struct function_invoker1

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

   1: 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則是用戶在實(shí)例化function模板時給出的模板參數(shù),我們寫的是function,于是:

  R = RT

  T0 = P

  所以,對于我們的錯誤示例,invoker_type的類型為:

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

  對于這樣一個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); //錯啦!瞧瞧f的型別,f接受一個P類型的參數(shù)嗎?編譯器在此打住。
   7:  //這行語句的另一個隱含的檢查是返回值類型匹配,f(...)返回RT1,而invoke須得返回RT
   8: }

看看最后一行語句,所有的檢查都在那里了——我們最終把檢查“委托”給了C++底層的類型系統(tǒng)。

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

   return f(a0);

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

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

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

   1: this->assign_to(mem_fn(f));

  mem_fun(f)返回一個仿函數(shù),它封裝了成員函數(shù)f,之后一切皆與仿函數(shù)無異。

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

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

  safe_bool慣用手法

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

   1:  
   2:   function f;
   3:   bool b=f;

 

  這顯然不妥,所以function用另一個巧妙的手法替代它,既所謂的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)的時候,編譯器會找到operator safe_bool(),從而將f轉(zhuǎn)型為safe_bool,這是個指針類型,if語句會正確判定它是否為空。而當(dāng)你試圖把f賦給其它類型的變量的時候則會遭到編譯期的拒絕——因為safe_bool無法向其它類型轉(zhuǎn)換。

  get_function_tag<>

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

   1: template struct is_pointer{enum{value=0};};
   2: mplate struct is_pointer{enum{value=1};};
   3: d::cout<::value; //這將輸出 1 

 

  也就是說int(*)(int)可以與T*形式匹配,匹配時T為int(int)。

  最后一些細(xì)節(jié)

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

   detail::function::any_pointer functor; //用于統(tǒng)一保存函數(shù)指針及仿函數(shù)對象指針

  2. 我沒有給出functor_manager的信息,實(shí)際上它與function的實(shí)現(xiàn)沒有太大關(guān)系,它負(fù)責(zé)copy和delete函數(shù)對象,如果必要的話。所以我將它略去,它的源碼在:”boost/function/function_base.hpp”里。

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

  本文只研究了int(int)型的情況,其它只是參數(shù)數(shù)目的改變而已。經(jīng)過宏的擴(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個版本,BOOST_FUNCTION_MAX_ARGS為一個宏,表示最多能夠接受有多少個參數(shù)的函數(shù)及仿函數(shù)對象,你可以重新定義這個宏為一個新值,以控制function所能支持的函數(shù)參數(shù)個數(shù)的最大值。其中的function0,function1,function2等名字也由宏擴(kuò)展出?! £P(guān)于作者:  劉未鵬是南大的學(xué)生,喜愛關(guān)于C++的一切,另外還喜歡的是.NET,雖然C#很爛,但是.NET的確不錯,正打算寫一個剖析Rotor(Shared source CLI)源代碼的系列,深掘.NET內(nèi)部的架構(gòu)及實(shí)現(xiàn),但由于正忙于考研,不知何年何月才能開始...   

于 2004-10-2 23:24 修改完畢 :-)

posted on 2012-07-25 11:29 zaccheo 閱讀(1566) 評論(0)  編輯 收藏 引用


只有注冊用戶登錄后才能發(fā)表評論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


導(dǎo)航

統(tǒng)計

常用鏈接

留言簿

隨筆分類(23)

隨筆檔案(26)

文章分類(1)

文章檔案(1)

csdn

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国外成人网址| 美女爽到呻吟久久久久| 久久久五月天| 久久精品视频在线免费观看| 香蕉av777xxx色综合一区| 亚洲天堂黄色| 久久疯狂做爰流白浆xx| 久久美女性网| 最新中文字幕亚洲| 一区二区高清视频| 欧美伊人精品成人久久综合97| 久久国产色av| 欧美高清自拍一区| 国产精品入口66mio| 激情国产一区| 一本一道久久综合狠狠老精东影业| 亚洲无亚洲人成网站77777| 欧美在线视频观看免费网站| 欧美aa国产视频| 一本综合久久| 久久精品国产精品亚洲| 欧美精品在线网站| 国产一本一道久久香蕉| 99天天综合性| 美女视频黄 久久| 欧美日韩ab片| 亚洲一区bb| 久久婷婷影院| 国产精品老女人精品视频| 有码中文亚洲精品| 亚洲欧美一区在线| 亚洲二区在线| 午夜精品视频一区| 欧美伦理a级免费电影| 国产专区综合网| 亚洲一二三区在线观看| 欧美成黄导航| 久久大综合网| 国产精品一级二级三级| 夜夜夜久久久| 亚洲电影第1页| 久久精品中文字幕一区二区三区| 欧美日韩一级片在线观看| 亚洲国产精品va在线观看黑人 | 狠狠综合久久av一区二区老牛| 夜夜嗨av一区二区三区四区| 欧美mv日韩mv国产网站app| 亚洲欧美综合v| 国产精品国产三级国产普通话三级 | 亚洲欧美一级二级三级| 欧美三级电影大全| 99视频精品免费观看| 亚洲成人在线网站| 美女国内精品自产拍在线播放| 精品不卡视频| 欧美a级片网| 久久伊人亚洲| 亚洲国产欧美精品| 欧美激情五月| 欧美风情在线观看| 亚洲裸体俱乐部裸体舞表演av| 欧美激情网友自拍| 欧美激情精品久久久久久免费印度| 狠狠色狠色综合曰曰| 美女黄色成人网| 欧美成年人网站| 99精品久久久| 亚洲视频在线观看免费| 国产乱码精品| 米奇777超碰欧美日韩亚洲| 久热精品视频在线观看一区| 亚洲国内自拍| 日韩亚洲欧美一区| 国产精品丝袜xxxxxxx| 久久久精彩视频| 欧美77777| 午夜精品久久久| 久久av一区二区三区亚洲| 亚洲经典一区| 亚洲一级片在线观看| 亚洲视频免费| 亚洲欧美色一区| 怡红院精品视频在线观看极品| 久久综合综合久久综合| 免费在线日韩av| 亚洲尤物影院| 久久久久国产精品午夜一区| 亚洲欧洲日产国码二区| 一区二区三区导航| 国产一区二区三区av电影| 亚洲国产另类精品专区 | 最新国产拍偷乱拍精品| 国产精品亚洲美女av网站| 久热精品在线| 欧美丝袜一区二区| 免费成人高清视频| 欧美三区美女| 牛牛影视久久网| 国产精品日日摸夜夜摸av| 欧美.www| 国产日产亚洲精品| 日韩午夜av| 在线观看日韩国产| 亚洲影院污污.| 亚洲美女在线视频| 久久精品免费电影| 香蕉亚洲视频| 欧美日韩国产综合新一区| 久久久久青草大香线综合精品| 欧美日本乱大交xxxxx| 老司机aⅴ在线精品导航| 欧美日韩一区二区三区高清| 另类激情亚洲| 国产欧美韩国高清| 日韩视频精品| 亚洲伦理在线免费看| 久久久久久久一区| 久久精品噜噜噜成人av农村| 欧美日韩一区二区三区在线 | 欧美激情欧美狂野欧美精品| 久久久久久色| 国产亚洲欧洲997久久综合| 99re66热这里只有精品4| 亚洲日本视频| 欧美成人精品一区二区| 欧美91大片| 亚洲国产精品久久精品怡红院| 午夜欧美不卡精品aaaaa| 欧美一区二区三区久久精品茉莉花| 欧美日韩你懂的| 亚洲免费电影在线| 国产精品99久久久久久久久久久久 | 午夜久久黄色| 国产精品美女久久久浪潮软件| 亚洲精品在线观看视频| 欧美主播一区二区三区| 亚洲破处大片| 午夜精品一区二区三区电影天堂 | 欧美国产成人在线| 女人色偷偷aa久久天堂| 国户精品久久久久久久久久久不卡| 亚洲一区在线观看免费观看电影高清| 99亚洲视频| 欧美日韩黄色大片| 一区二区三区久久| 香蕉久久一区二区不卡无毒影院| 国产精品夜夜夜| 欧美一区永久视频免费观看| 久久露脸国产精品| 亚洲国产国产亚洲一二三| 欧美国产精品久久| 夜夜嗨av一区二区三区免费区| 亚洲一区二区三区久久| 国产欧美一二三区| 久久伊人亚洲| 亚洲精品视频啊美女在线直播| 亚洲一区二区三区色| 国产日韩亚洲欧美综合| 久久久久久欧美| 91久久精品国产91久久性色| 亚洲一区二区三区777| 国产亚洲午夜高清国产拍精品| 久久久久网站| 99精品免费视频| 裸体女人亚洲精品一区| 一区二区三区高清在线观看| 国产欧美三级| 欧美女主播在线| 欧美一区二区三区四区在线| 亚洲电影免费观看高清| 亚洲欧美日韩中文视频| 1204国产成人精品视频| 国产精品白丝av嫩草影院| 久久嫩草精品久久久精品一| 一区二区国产在线观看| 免费91麻豆精品国产自产在线观看| 日韩小视频在线观看专区| 国产欧美另类| 欧美日韩一本到| 久久免费视频观看| 宅男噜噜噜66国产日韩在线观看| 老司机午夜免费精品视频| 在线一区视频| 亚洲精品久久| 在线播放一区| 国产精品永久| 欧美日韩一卡| 欧美激情亚洲| 久久蜜臀精品av| 亚洲欧美日韩综合| 9色精品在线| 亚洲精品黄色| 欧美freesex交免费视频| 欧美在线综合视频| 亚洲影音一区| 亚洲视频国产视频| 夜夜爽99久久国产综合精品女不卡 | 久久亚洲综合网| 亚洲女同精品视频| 99视频精品在线|