亚洲香蕉成人av网站在线观看_欧美精品成人91久久久久久久_久久久久久久久久久亚洲_热久久视久久精品18亚洲精品_国产精自产拍久久久久久_亚洲色图国产精品_91精品国产网站_中文字幕欧美日韩精品_国产精品久久久久久亚洲调教_国产精品久久一区_性夜试看影院91社区_97在线观看视频国产_68精品久久久久久欧美_欧美精品在线观看_国产精品一区二区久久精品_欧美老女人bb

首頁 > 學院 > 開發設計 > 正文

Boost源碼剖析:C++泛型函數指針類

2019-11-17 05:10:51
字體:
來源:轉載
供稿:網友
前奏

  如你所知,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)與函數指針相比應該有以下一些優勢:

  ¨ 同一個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)
  ¨ function應能夠和參數綁定以及其它function-construction庫協同工作。例如,function應該也能夠接受std::bind1st返回的仿函數。這一點其實由第一點已經有所保證。

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

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

R1 (T0,T1,T2,...,TN) => FunctionType1
R2 (P0,P1,P2,...,PN) => FunctionType2
  兩種類型的函數(廣義),只要滿足:

  1. R2能夠隱式轉換為R1

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

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

  后面你會看到,boost::function通過所謂的invoker非常巧妙地實現了這點,并且阻止了被形式不兼容的函數賦值的操作。 更多文章 更多內容請看C/C++技術專題專題,或
探險

  好吧,預備好,我們要出發了,進行深入源碼世界的探險。

  先看一個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) //按值傳遞,類型退化
{
 static_cast<int>(ft); //引發編譯錯誤,從而看出ft的類型為退化后的函數指針
}

int g(int); //函數g,名字g的類型為int(int)
test_func_type(g); //注重,并非&g,參數g的類型將會退化為函數指針類型
int (&ref_f)(int) = g; //注重,并非“= &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:
  function() : base_type() {} //默認構造
  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() {} //這個構造函數的作用在下面解釋
 self_type& operator=(const self_type& f) //同類型function對象之間應該能夠賦值
 {
  self_type(f).swap(*this); //swap技巧,細節見《Effective STL》
  return *this;
 }
 ...
};

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可以被賦給任何指針,所以它被選出,執行缺省的構造行為。 更多文章 更多內容請看C/C++技術專題專題,或
基類 functionN

  function的骨架就這些。也許你會問,function作為一個仿函數類,怎么沒有重載operator()——這可是身為仿函數的標志?。e急,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;
  function1() : function_base(),invoker(0){}//默認構造
  template<typename Functor>
  function1(Functor const & f, //模板構造函數
   typename enable_if<...>::type = 0) :
   function_base(),
   invoker(0)
   {
    this->assign_to(f); //這兒真正進行賦值,assign_to的代碼在下面列出
   }

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

  result_type operator()(T0 a0) const //身為仿函數的標志!
  {
   //下面負責調用指向的函數

   if (this->empty())
    boost::throw_exception(bad_function_call());
    //這里進行真正的函數調用,使用invoker

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

  template<typename Functor>
  void assign_to(Functor f) //所有的構造函數都調用它!具有多個重載版本。
  {
   //以一個get_function_tag萃取出Functor的類別(category)!
   typedef typename detail::function::get_function_tag<Functor>::type tag;
   this->assign_to(f, tag());//根據不同類別的Functor采取不同的assign策略!
  }
  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 detail::function::get_function_invoker1<FunctionPtr,R,T0>::type invoker_type;
  invoker = &invoker_type::invoke; //invoke是static成員函數

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

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

...

typedef internal_result_type (*invoker_type)(detail::function::any_pointer,T0);
invoker_type invoker; //重要成員,負責調用函數!

};
  你可能已經被這段“夾敘夾議”的代碼弄得頭昏腦漲了,但這才剛剛開始!

  function的底層存儲機制

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

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

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


union any_pointer
{
void* obj_ptr; //任意仿函數對象指針都可以用static_cast<>轉型為void*型
const void* const_obj_ptr; //為const仿函數預備的
void (*func_ptr)(); //任意函數指針都可以用reinterPRet_cast<>轉型為void(*)()型
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<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中也對該函數模板做了擴充,使它可以接受任意多個參數的成員函數。 更多文章 更多內容請看C/C++技術專題專題,或
做一個,送一個——invoker的額外好處

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


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

function<RT(P)> f_ptr; //RT(P)函數類型,同樣假定RT,P已定義

f_ptr = &f; //類型不兼容,錯誤!
  這就會導致編譯錯誤,錯誤發生在invoke靜態成員函數中。下面我就為你解釋為什么。

  我想你對function_invoker1考的三個模板參數仍然心存迷惑,我們再一次往返顧一下其聲明:

template<typename FunctionPtr,typename R,typename T0>

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

typedef typename detail::function::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)
{
 RT1 (*f)(P1,P2)= //FunctorPtr f =reinterpret_cast<RT1(*)(P1,P2)>(function_ptr.func_ptr);
 return f(a0); //錯啦!瞧瞧f的型別,f接受一個P類型的參數嗎?編譯器在此打住。
 //這行語句的另一個隱含的檢查是返回值類型匹配,f(...)返回RT1,而invoke須得返回RT
}
  看看最后一行語句,所有的檢查都在那里了——我們最終把檢查“委托”給了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;

bool 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等名字也由宏擴展出。 更多文章 更多內容請看C/C++技術專題專題,或

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
亚洲香蕉成人av网站在线观看_欧美精品成人91久久久久久久_久久久久久久久久久亚洲_热久久视久久精品18亚洲精品_国产精自产拍久久久久久_亚洲色图国产精品_91精品国产网站_中文字幕欧美日韩精品_国产精品久久久久久亚洲调教_国产精品久久一区_性夜试看影院91社区_97在线观看视频国产_68精品久久久久久欧美_欧美精品在线观看_国产精品一区二区久久精品_欧美老女人bb
最近2019中文字幕在线高清| 5252色成人免费视频| 亚洲综合精品伊人久久| 欧美在线影院在线视频| 日韩成人xxxx| 久久6精品影院| 色婷婷av一区二区三区久久| 精品久久久久久久久久久久久| 久久久综合av| 伊人久久久久久久久久久久久| 亚洲午夜激情免费视频| 欧美日韩国产精品一区| 狠狠色狠狠色综合日日小说| 91久久精品美女| 日韩av大片免费看| 国产成人精品免高潮费视频| 欧美日韩激情视频| 中文字幕国产精品久久| 久久影院免费观看| 日韩欧亚中文在线| 精品爽片免费看久久| 国产日韩欧美另类| 国产69久久精品成人| 日韩女在线观看| 97国产精品视频| 久久理论片午夜琪琪电影网| 视频在线观看99| 亚洲天堂久久av| 亚洲精品免费av| 91亚洲精品久久久久久久久久久久| 91香蕉嫩草影院入口| 日韩激情第一页| 国产一区视频在线播放| 97久久久免费福利网址| 国产精品88a∨| 欧美日韩国产第一页| 疯狂做受xxxx高潮欧美日本| 欧美一级淫片丝袜脚交| 亚洲精品第一国产综合精品| 午夜精品久久久久久久99热| 伊是香蕉大人久久| 91亚洲精品在线观看| 亚洲精品按摩视频| 一本色道久久综合狠狠躁篇的优点| 国产日本欧美在线观看| 日韩国产精品视频| 亚洲性线免费观看视频成熟| 日本免费久久高清视频| 欧洲亚洲妇女av| www.午夜精品| 亚洲人成电影网站色www| 欧美成人全部免费| 久久在精品线影院精品国产| 国产成人在线亚洲欧美| 国产97在线播放| 另类天堂视频在线观看| 国产成人亚洲综合| 欧美日韩一区二区免费视频| 日韩在线一区二区三区免费视频| 亚洲黄色免费三级| 久操成人在线视频| 欧美午夜宅男影院在线观看| 成人免费在线视频网址| 日本伊人精品一区二区三区介绍| 色综合久久精品亚洲国产| 亚洲天堂网在线观看| 在线观看久久久久久| 精品亚洲一区二区三区在线播放| 国产精品99一区| 成人美女av在线直播| 国产99视频精品免视看7| 亚洲综合中文字幕在线观看| 美日韩精品视频免费看| 欧美日产国产成人免费图片| 亚洲一区二区三区在线免费观看| 亚洲精品98久久久久久中文字幕| 91av视频在线免费观看| 成人免费视频在线观看超级碰| 欧美电影在线免费观看网站| 欧美性猛交xxxxx免费看| 日韩福利在线播放| 精品一区二区三区三区| 一区二区三区黄色| 久久久www成人免费精品张筱雨| 久青草国产97香蕉在线视频| 欧洲成人在线观看| 日韩欧美中文字幕在线播放| 日韩在线不卡视频| 色婷婷av一区二区三区在线观看| 一区二区三区视频在线| 精品国产一区二区三区久久狼5月| 亚洲欧美日韩直播| 色七七影院综合| 国产亚洲视频在线| 午夜伦理精品一区| 久久久久久久久久婷婷| 亚洲精品www久久久久久广东| 92版电视剧仙鹤神针在线观看| 国产91av在线| 精品亚洲精品福利线在观看| 国产精品久久久久久久久影视| 亚洲精品97久久| 日韩一二三在线视频播| 国产成人在线播放| 91av免费观看91av精品在线| 亚洲国产欧美一区二区三区久久| 色噜噜狠狠色综合网图区| 亚洲欧美综合图区| 福利一区视频在线观看| 国产婷婷色综合av蜜臀av| 69影院欧美专区视频| 亚洲欧美制服第一页| 欧美国产亚洲精品久久久8v| 69av成年福利视频| 91精品久久久久久久久| 欧美性理论片在线观看片免费| 亚洲免费一级电影| 69**夜色精品国产69乱| 中文在线资源观看视频网站免费不卡| 亚洲va久久久噜噜噜久久天堂| 日本一区二三区好的精华液| www.久久色.com| 欧美最近摘花xxxx摘花| 69精品小视频| 久久精品国产96久久久香蕉| 亚洲精品久久久久久久久久久| 怡红院精品视频| 在线视频欧美日韩| 亚洲国产精品网站| 国产丝袜一区二区三区| 中文字幕国内精品| 国产性色av一区二区| 精品久久久久久久久中文字幕| 国产亚洲精品一区二区| 日韩视频免费大全中文字幕| 亚洲精品99久久久久中文字幕| 国产精品专区第二| 亚洲丝袜在线视频| 国产精品久久9| 69久久夜色精品国产7777| 一区二区国产精品视频| 日韩av免费看网站| 国产视频999| 日本国产一区二区三区| 欧美成人自拍视频| 亚洲人成网站色ww在线| 亚洲欧美一区二区三区在线| 成人高h视频在线| 亚洲精品久久久久国产| 国产精品视频区1| 青青a在线精品免费观看| 国产91精品最新在线播放| 国产成一区二区| 51久久精品夜色国产麻豆| 欧美一级视频一区二区| 欧美视频在线免费看| 91沈先生在线观看| 91精品久久久久久久久久入口| 欧美午夜久久久| 久久久国产一区| 国产精品视频最多的网站| 久久99亚洲精品| 欧美资源在线观看| 亚洲女同精品视频|