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

loop_in_codes

低調(diào)做技術(shù)__歡迎移步我的獨(dú)立博客 codemaro.com 微博 kevinlynx

實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針

作者:Kevin Lynx

需求:

開發(fā)一種組件,用以包裝C函數(shù)、通常的函數(shù)對(duì)象、成員函數(shù),使其對(duì)外保持一種一致的接口。我將最終的
組件稱為functor,這里的functor與loki中的functor以及boost中的function功能一致,同STL中的functor
在概念層次上可以說也是一樣的。那么,functor其實(shí)也可以進(jìn)一步傳進(jìn)其他functor構(gòu)成新的functor。

C++世界里還有一種組件,稱做bind(er),例如STL中的binder1st、binder2nd,以及boost中的bind。所謂
的bind是將一些參數(shù)與函數(shù)之類的關(guān)聯(lián)起來,當(dāng)執(zhí)行該bind創(chuàng)建的對(duì)象時(shí),庫會(huì)自動(dòng)將之前bind的參數(shù)傳
遞給bind創(chuàng)建的對(duì)象。bind創(chuàng)建出來的對(duì)象在某種程度上來說也是一種functor。

實(shí)現(xiàn):

包裝C函數(shù)和函數(shù)對(duì)象的functor事實(shí)上是一致的,而實(shí)現(xiàn)包裝成員函數(shù)的functor則需要多傳入一個(gè)對(duì)象參數(shù)。
因此這里先討論包裝C函數(shù)和函數(shù)對(duì)象的functor。

包裝C函數(shù):

思考下各種不同的C函數(shù)的共同點(diǎn)和不同點(diǎn),共同點(diǎn)就是這些函數(shù)都有一個(gè)返回值,參數(shù)個(gè)數(shù)可能相同,可能
不同,參數(shù)類型可能相同可能不同??紤]到模板對(duì)于類型的泛化特性,對(duì)于參數(shù)類型來說,可以輕松實(shí)現(xiàn)無
關(guān)性。而至于參數(shù)個(gè)數(shù)的泛化,則要復(fù)雜點(diǎn)。這里先考慮實(shí)現(xiàn)參數(shù)個(gè)數(shù)為1個(gè)的functor:

template <typename _R, typename _P1>
class functor
{
public:
 typedef _R (
*func_type)( _P1 );
public:
 
explicit functor( const func_type &func ) :
  _func( func )
 
{
 }

 
 _R 
operator() ( _P1 p )
 
{
  
return _func( p );
 }


private:
 func_type _func;
}
;


要使用這個(gè)類模板,可以這樣:

functor<intint> cmd( func ); // int func( int )
cmd( 1 );


這樣,functor這個(gè)類模板就可以保存所以只有一個(gè)參數(shù)返回值任意的函數(shù)。但是這里首要的問題是,這個(gè)
類模板無法保存具有相同類型的函數(shù)對(duì)象,例如函數(shù)對(duì)象:

struct Func
{
    
int operator() ( int i )
    
{
        
return i;
    }

}
;


Func obj; 因?yàn)閛bj的類型事實(shí)上是Func,并不是一般的函數(shù)類型(例如 int (*)(int) )。那么,這里就需要
將functor::func_type這個(gè)typedef泛化。

包裝函數(shù)對(duì)象

要實(shí)現(xiàn)這個(gè)目的,其實(shí)并不那么容易。一種比較直接的方法是我們把functor::func_type通過模板參數(shù)顯示地讓用戶配置,
例如:

template <typename _R, typename _P1, typename _FuncType>
class functor
{
public:
 typedef _FuncType func_type;
 
//以下內(nèi)容相同


那么,現(xiàn)在就可以這樣使用functor:

functor<intintint(*)(int)> cmd( func );
cmd( 
1 );
// 測試函數(shù)對(duì)象
Func obj;
functor
<intint, Func> cmd2( obj );
cmd2( 
2 );


自動(dòng)推導(dǎo)類型:

但是,這種顯示指定functor保存的函數(shù)(函數(shù)對(duì)象)的類型顯然是不方便的。我希望functor可以自動(dòng)獲取我們要
保存的東西(C函數(shù),函數(shù)對(duì)象,為方便起見,以下全部簡稱為函數(shù))的類型。而一個(gè)函數(shù)模板正可以做到這一點(diǎn)。
以下簡寫很多思考過程,直接給出一個(gè)解決方案:

template <typename _R, typename _P1>
struct handler_base
{
 
virtual _R operator() ( _P1 ) = 0;
}
;

template 
<typename _R, typename _P1, typename _FuncType>
class handler : public handler_base<_R, _P1>
{
public:
 typedef _FuncType func_type;
public:
 handler( 
const func_type &func ) :
   _func( func )
 
{
 }


 _R 
operator() ( _P1 p )
 
{
  
return _func( p );
 }


public:
 func_type _func;
}
;

template 
<typename _R, typename _P1>
class functor
{
public:
 typedef handler_base
<_R, _P1> handler_type ;
public:
 template 
<typename _FuncType>
 functor( _FuncType func ) :
  _handler( 
new handler<_R, _P1, _FuncType>( func ) )
 
{
 }

 
 
~functor()
 
{
  delete _handler;
 }


 _R 
operator() ( _P1 p )
 
{
  
return (*_handler)( p );
 }


private:
 handler_type 
*_handler;
}
;


代碼多了一倍,還增加了多態(tài)機(jī)制,使用了動(dòng)態(tài)內(nèi)存分配(這總會(huì)為我們?cè)黾勇闊赃@些,就是為了提供
給用戶一個(gè)方便一致的接口?,F(xiàn)在我們可以這樣使用functor:

functor<intint> cmd1( func );
cmd1( 
1 );

Func obj;
functor
<intint> cmd2( obj );
cmd2( 
2 );


雖然目標(biāo)實(shí)現(xiàn)了,可是看上去并不完美。礙眼的就是那個(gè)virtual,以及new/delete。不過因?yàn)檫@里離我的最終
目標(biāo)還很遠(yuǎn),所以姑且不管這些。接下來要實(shí)現(xiàn)的是讓functor支持任意個(gè)參數(shù)(事實(shí)上任意個(gè)是不可能的)。

讓更多的類型加入進(jìn)來:

這里支持任意個(gè)參數(shù)似乎不現(xiàn)實(shí),因?yàn)镃++并不支持這樣的語法形式:

template <typename _R, >
class functor;


也就是說模板并不支持可變參數(shù)。(可變參數(shù)那是C里面的東西,C++本身就不鼓勵(lì))

這里,最簡單的實(shí)現(xiàn)方法就是定義各種functor,支持0個(gè)參數(shù)的functor,支持一個(gè)參數(shù)的functor(我們以上實(shí)現(xiàn)的),
支持兩個(gè)參數(shù)的functor,等等。相應(yīng)的,我們給每一個(gè)functor命名為functor0,functor1,functor2,。。。

這確實(shí)是一種樸實(shí)的解決方法,但同時(shí)看上去也確實(shí)很不優(yōu)雅。我們其實(shí)完全可以通過一種模板技術(shù)讓functor1這種
丑陋的命名方式消失,這就是模板偏特化(partial specialization)。

Loki中的魔法:

首先我們要讓functor這個(gè)頂層類可以看上去似乎支持可變長度的模板參數(shù)。這個(gè)可以通過loki的TypeList實(shí)現(xiàn)。但是
我們這里并不會(huì)用到特別復(fù)雜的TypeList技術(shù)。所謂TypeList,大致上核心在于以下類型:

template <typename _T, typename _U>
struct type_list
{
 typedef _T head_type;
 typedef _U tail_type;
}
;


然后我們可以以一種遞歸的方式去容納任意長度的類型列表(所謂type list):
type_list<int, type_list<char, float> >
在實(shí)際實(shí)現(xiàn)時(shí),我們通常會(huì)為每一個(gè)type list添加一個(gè)在loki中叫null_type的類型,就像C字符串末尾的'\0'一樣:
type_list<int, type_list<char, null_type> >
而null_type很簡單,就是一個(gè)沒有任何東西的空類型:

struct null_type { };


為了更方便地產(chǎn)生type_list,我們按照loki中的做法,定義一系列的宏:

#define TYPE_LIST1( T1 ) type_list<T1, null_type>
#define TYPE_LIST2( T1, T2 ) type_list<T1, TYPE_LIST1( T2 )>
#define TYPE_LIST3( T1, T2, T3 ) type_list<T1, TYPE_LIST2( T2, T3 )>
/// etc


注:以上內(nèi)容基本和<C++設(shè)計(jì)新思維>部分內(nèi)容相同

講述了以上基本內(nèi)容(我希望你能理解),接下來我要闡述下我的目的。我會(huì)把新的functor定義成:

template <typename _R, typename _ParamList>
class functor;


如你所見,這和之前的functor本質(zhì)上是一樣的,我只不過改變了一個(gè)模板參數(shù)的名字(_ParamList)?,F(xiàn)在當(dāng)我們使用
functor的時(shí)候,會(huì)這樣:

functor<voidvoid>
functor
<int, TYPE_LIST1( char )>
functor
<void, TYPE_LIST2( charfloat )>


我們回頭看下之前創(chuàng)建的functor模塊的三個(gè)類是如何相互關(guān)聯(lián)的:functor提供給外部用戶接口,handler保存函數(shù)、回調(diào)
函數(shù),handler_base則主要是提供給functor一個(gè)可以保存的類型(所以functor里保存的是functor_base)以及聲明各種接口。
為什么需要提供handler_base,而不直接保存handler?因?yàn)閔andler需要保存函數(shù)的類型_FuncType,而這個(gè)類型只能在functor構(gòu)造
函數(shù)里被提取出來。局限于這個(gè)原因,我加入了handler_base,并不得不加入了virtual,而為了滿足virtual的需要,我進(jìn)一步
不得不將handler方在堆棧上。

現(xiàn)在,我要實(shí)現(xiàn)通過functor不同的模板參數(shù)(主要在于_ParamList),產(chǎn)生不同的handler_base。關(guān)鍵在于我要產(chǎn)生各種不同的
handler_base!現(xiàn)在我省略很多思考過程,直接給出一種架構(gòu):

 

template <typename _R, typename _ParamList>
struct handler_base;

template 
<typename _R>
struct handler_base<_R, void> : public handler_type_base<_R>
{
 
virtual _R operator() ( void ) = 0;
}
;

template 
<typename _R, typename _P1>
struct handler_base<_R, TYPE_LIST1( _P1 )> : public handler_type_base<_R>
{
 typedef _P1 param1_type;

 
virtual _R operator() ( _P1 ) = 0;
}
;

/// TODO:添加更多類型的偏特化版本

template 
<typename _R, typename _ParamList, typename _FuncType>
class handler : public handler_base<_R, _ParamList>
{
public:
 typedef _FuncType func_type;

 typedef handler_base
<_R, _ParamList> base_type;
 typedef typename base_type::param1_type param1_type;
 
/// TODO:更多的類型定義
public:
 handler( 
const func_type &func ) :
   _func( func )
 
{
 }


    _R 
operator() ()
 
{
  
return _func();
 }


 _R 
operator() ( param1_type p )
 
{
  
return _func( p );
 }

 
///省略部分代碼
 
/// functor

template <typename _R, typename _ParamList>
class functor
{
public:
 typedef handler_base
<_R, _ParamList> handler_type ;

 typedef typename handler_type::param1_type param1_type;
 typedef typename handler_type::param2_type param2_type;
 typedef typename handler_type::param3_type param3_type;
 
/// TODO:更多類型
public:
 template 
<typename _FuncType>
 functor( _FuncType func ) :
  _handler( 
new handler<_R, _ParamList, _FuncType>( func ) )
 
{
 }

 
 
~functor()
 
{
  delete _handler;
 }


 _R 
operator() ()
 
{
  
return (*_handler)();
 }


 _R 
operator() ( param1_type p )
 
{
  
return (*_handler)( p );
 }

 
///省略部分代碼

 
現(xiàn)在,各種偏特化版本的handler_base,其實(shí)就相當(dāng)于實(shí)現(xiàn)了各種參數(shù)個(gè)數(shù)的functor,也就是functor0,functor1等。但是
現(xiàn)在有個(gè)很直接的問題,例如當(dāng)functor<void, int>定義了一個(gè)參數(shù)時(shí),functor::handler_type里就沒有param2_type之類的
類型定義,使用的偏特化版本handler_base也沒有部分param之類的類型定義。這會(huì)引起編譯出錯(cuò)。為了解決這個(gè)辦法,我不得
不再引入一個(gè)用于類型定義的基類:

template <typename _R>
struct handler_type_base
{
 typedef _R result_type;
 typedef null_type param1_type;
 typedef null_type param2_type;
 typedef null_type param3_type;
 
/// TODO:添加更多類型定義
}
;


然后各種偏特化handler_base版本從handler_type_base繼承:

template <typename _R, typename _P1, typename _P2>
struct handler_base<_R, TYPE_LIST2(_P1, _P2 )> : public handler_type_base<_R>
{
 typedef _P1 param1_type;
 typedef _P2 param2_type;

 
virtual _R operator() ( _P1, _P2 ) = 0;
}
;


解決了這個(gè)編譯錯(cuò)誤問題,整個(gè)functor就基本實(shí)現(xiàn)了?,F(xiàn)在可以這樣使用functor:
沒有參數(shù)的函數(shù): 

functor<voidvoid> cmd4( func3 );
cmd4();


兩個(gè)參數(shù)的函數(shù):

functor<void, TYPE_LIST2( intchar)> cmd3( func2 );
cmd3( 
3'a' );


我稍微提下編譯器大致的處理方法:當(dāng)functor<void, void> cmd4( func3 )時(shí),functor::handler_type為handler_base<void, void>偏特
化版本。該版本定義了void operator()()函數(shù)。當(dāng)cmd4()時(shí),就會(huì)調(diào)用到handler::operator()()函數(shù)。該函數(shù)回調(diào)func3函數(shù),完成調(diào)用。

完結(jié),將成員函數(shù)包含進(jìn)來:

 關(guān)于包裝成員函數(shù),其實(shí)很簡單,只是在調(diào)用時(shí)需要一個(gè)該類的對(duì)象而已。這里直接從handler_base派生:

 template <typename _R, typename _ParamList, typename _FuncType, typename _ObjType>
class mem_handler : public handler_base<_R, _ParamList>
{
public:
 typedef _FuncType func_type;
 typedef _ObjType obj_type;

 typedef handler_base
<_R, _ParamList> base_type;
 typedef typename base_type::param1_type param1_type;
 typedef typename base_type::param2_type param2_type;
 typedef typename base_type::param3_type param3_type;

public:
 mem_handler( obj_type 
&obj, const func_type &func ) :
  _obj( obj ), _func( func )
 
{
 }


 _R 
operator() ()
 
{
  
return (_obj.*_func)();
 }


 _R 
operator() ( param1_type p )
 
{
  
return (_obj.*_func)( p );
 }


 _R 
operator() ( param1_type p1, param2_type p2 )
 
{
  
return (_obj.*_func)( p1, p2 );
 }


private:
 obj_type 
&_obj;
 func_type _func;
}
;


在functor中加入另一個(gè)構(gòu)造函數(shù):
 

template <typename _ObjType, typename _FuncType>
functor( _ObjType 
&obj, _FuncType func ) :
 _handler( 
new mem_handler<_R, _ParamList, _FuncType, _ObjType>( obj, func ) )
{
}


一切都很完美。使用時(shí):

Test obj2; // Test是一個(gè)類
functor<void, TYPE_LIST1( int)> cmd5( obj2, &Test::display );
cmd5( 
1 );

 

結(jié)束語:
雖然我們最終的目的實(shí)現(xiàn)了,但是這還是不夠完美。我們還要處理functor的拷貝行為,因?yàn)閒unctor天生就是被用來
四處拷貝的。一旦涉及到拷貝,我們就不得不小心翼翼地處理好functor中的那個(gè)被new出來的對(duì)象。作為一個(gè)C++程序員,
你應(yīng)該時(shí)刻警惕放在heap上的東西,建立對(duì)heap上的警覺感是很重要的。這里我不得不承認(rèn)在后期實(shí)現(xiàn)中,我直接搬了
loki中的很多方案。如果你不想讓這個(gè)functor看上去那么優(yōu)雅,那你完全可以寫出functor0,functor1之類的東西。

參考資料:
<C++ template>類模板的偏特化章節(jié)
<Modern C++ design>type list, functor章節(jié)
loki::functor源代碼
boost:;function源代碼
stl::bind1st源代碼
stl::ptr_fun相關(guān)源代碼

 

 

posted on 2008-03-17 11:13 Kevin Lynx 閱讀(7630) 評(píng)論(15)  編輯 收藏 引用 所屬分類: c/c++

評(píng)論

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2008-03-17 16:43 夢(mèng)在天涯

functor 確實(shí)是比STL中的一大堆好用多了!統(tǒng)一!  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2008-03-17 16:57 魔域私服

http://www.zhaomysf.com.cn  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-04 13:47 deadlm

這叫什么東西啊:functor<void, TYPE_LIST2( int, char)>
實(shí)現(xiàn)的非常差勁
就這樣還敢說優(yōu)雅
看到定義個(gè)變量跟水蛇一樣長的東西就煩,一個(gè)詞評(píng)價(jià)就是丑陋
等做到functor<void,int,char>再來說優(yōu)雅,這是最基本的實(shí)現(xiàn)要求
  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-04 17:56 Kevin Lynx

@deadlm
并不見得functor<void, int, char>就比function< void, TYPE_LIST2( int, char )>好。
functor<void, int, char>是需要諸如:
template <typename R, typename P1>
class lua_binder<R ( P1 )>
的語法支持。而并不見得所有的編譯器都支持。另外,我沒有提供這樣的接口也并不見得我寫不出來:
http://www.shnenglu.com/kevinlynx/archive/2008/08/20/59451.html
http://www.shnenglu.com/kevinlynx/archive/2008/08/13/58684.html
另外,這里的TYPE_LIST機(jī)制取自于loki庫。佩服哥們有蔑視loki庫的魄力。  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-05 14:19 deadlm

首先,我連現(xiàn)在實(shí)現(xiàn)的functor<void, int, char>類型都嫌煩,考慮有沒有更加簡化的實(shí)現(xiàn)方法,這個(gè)類的本質(zhì)就是個(gè)指針,還要這么多煩雜的東西干嘛
說到編譯器的問題,只要符合c++標(biāo)準(zhǔn)和主要的幾個(gè)編譯器沒問題就行,其它的不行那是它本身的實(shí)現(xiàn)有問題,誰能考慮那么多,要有人做個(gè)基本編譯不了什么東西的編譯器出來,難道還要顧慮它不成?
任何庫的某個(gè)實(shí)現(xiàn)都是可以“蔑視”的,就如更加歷經(jīng)考驗(yàn)的stl里的string,純粹就是個(gè)指針盒,我就自寫了個(gè)字符串類代替,而且基本沒在自己的代碼里再用過std::string,只要能兼容它,性能比它更好,犯得著理它嗎  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-05 14:22 deadlm

還有就是
干嘛要用class lua_binder<R ( P1 )> 這種型式?  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-05 16:50 Kevin Lynx

@deadlm
functor這種東西本質(zhì)上確實(shí)如你所說是保存一個(gè)“函數(shù)”指針。其實(shí)偏要加上返回值類型以及各個(gè)參數(shù)的類型,我覺得主要還是哄好編譯器。
void func( int );
void func( int, char );
這兩個(gè)函數(shù)在語言層次畢竟屬于不同的類型,functor在回調(diào)他們時(shí),需要知道傳多少個(gè)參數(shù)。這些信息都需要保存起來。
template在整個(gè)C++中完全屬于一種花哨的東西,當(dāng)然不可否認(rèn)其作用,如果實(shí)在煩這些,可以無視這些語言特性。

之所以我不敢“蔑視”STL、LOKI之類的庫,是因?yàn)槲易哉J(rèn)能力沒到這級(jí)別。也許以后我可以。

class lua_binder<R ( P1 )> 是lua_binder的偏特化,因?yàn)閘ua_binder本體只有一個(gè)類型參數(shù),所以,不能寫:
class lua_binder<R, P1>。這么說來,在支持多參數(shù)函數(shù)的情況下,要么使用functor<int, TYPE_LIST1( ...的形式,要么使用functor<int (int)>的形式。對(duì)于functor<int, int>的形式,你指的是怎樣的實(shí)現(xiàn)?(很久沒在弄模板這些東西,有點(diǎn)生疏)。
  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-05 22:01 deadlm

整個(gè)周日下午就在弄這個(gè),終于搞掂,發(fā)現(xiàn)這個(gè)實(shí)現(xiàn)用來做事件模型更適當(dāng)

大概因?yàn)槲易铋_始選擇的語言是pascal,所以我對(duì)cc里聲明個(gè)變量就要一長串字符非常厭煩,純粹是長久養(yǎng)成的習(xí)慣。

嗯。。。。。自己看了自己在上面的第一個(gè)貼,好像語氣有問題,如果Kevin Lynx 覺得有冒犯,那就不好意思了。  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-05 22:09 deadlm

其實(shí)加幾個(gè)輔助類進(jìn)行記錄就可以不用class lua_binder<R ( P1 )> 的形式,
當(dāng)然這是取巧的作法,你這樣做才是真正實(shí)現(xiàn)無限參數(shù)的方法,而且內(nèi)部實(shí)現(xiàn)的時(shí)候看起來會(huì)非常丑陋,因?yàn)榇a量實(shí)在太多。僅在用起來時(shí)看似簡潔。
我以前第一次寫的時(shí)候還寫過這樣的東西呢
#define MFuncP(...) LLib::Member_Function_Pointer<__VA_ARGS__>::core_b5_c12  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-05 22:40 Kevin Lynx

@deadlm
沒用過pascal,不同語言帶來的感受肯定不同。:)

functor之類的東西,為了支持各種不同類型的函數(shù),其內(nèi)部實(shí)現(xiàn)確實(shí)很惡心,而且少不了復(fù)制代碼。后來發(fā)現(xiàn)有宏遞歸這種東西(http://www.shnenglu.com/kevinlynx/archive/2008/08/20/59451.html boost中甚至直接有個(gè)macro庫),雖然內(nèi)部實(shí)現(xiàn)可以少寫些代碼(用宏來幫助生成),但是其代碼看起來更糾結(jié)。:D

  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-05 23:51 deadlm

睡前再說幾句:
我現(xiàn)在實(shí)現(xiàn)的無需聲明參數(shù)函數(shù)指針的內(nèi)部實(shí)現(xiàn)才叫惡心呢,先是用了八九個(gè)完全不同的輔助類,然后每個(gè)輔助類還重復(fù)了N次,這些還不是最惡心的,最惡心還是因?yàn)橐M(jìn)行類型弱化,我是直接查詢了模板特化的內(nèi)存序列,硬著上的,那部分代碼我現(xiàn)在看到就有全部選擇然后按下delete鍵的沖動(dòng)。
只在vc和gcc上試過,還沒在其它編譯測試過,都不知道行不行。

完事后想起一件事,以前用過php,里面的函數(shù)指針好像就是無類型的,是不是應(yīng)該找它的源碼剽上一剽呢?  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-07 16:13 deadlm

測試過后,終于出問題,不支持返回值為void。。。。。。
結(jié)果只能改成這樣
funcbp fp;
fp.set(testfunc,a);
fp();
本來找到你的blog就是想剽上一剽的。。。。。。。嘿嘿
結(jié)果找了不少地方,你這個(gè)還算離我的目的最相近的,其它的很多實(shí)現(xiàn)更離譜
離完全的無類型函數(shù)指針就差一步啊,就因?yàn)関oid不能引用。。。。。。
算了,不折騰了,拜拜
  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2009-07-08 10:30 Kevin Lynx

@deadlm
- -|
  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2010-02-27 16:05 G_cofa

呵呵,好。  回復(fù)  更多評(píng)論   

# re: 實(shí)現(xiàn)functor - 增強(qiáng)型的函數(shù)指針 2010-06-02 14:55 欣萌

這是我看過的最好的。  回復(fù)  更多評(píng)論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            久久综合色播五月| 日韩午夜电影在线观看| 亚洲黄色大片| 日韩亚洲欧美高清| 欧美在线影院| 欧美另类视频| 国产亚洲欧美aaaa| 日韩亚洲国产欧美| 久久久精品动漫| 亚洲精品美女在线| 久久精品国产亚洲精品| 欧美久久久久免费| 激情小说另类小说亚洲欧美| 亚洲香蕉视频| 欧美激情一区二区三区不卡| 亚洲欧美日韩国产成人精品影院| 美女视频黄a大片欧美| 国产精品视频免费在线观看| 91久久国产综合久久| 久久xxxx精品视频| 日韩视频在线播放| 久久综合色88| 国产一区二区成人| 亚洲在线一区二区| 亚洲高清免费| 久久精品官网| 国产精品每日更新| 国产精品夜夜嗨| 日韩亚洲不卡在线| 蜜臀av一级做a爰片久久| 亚洲一区自拍| 欧美日韩国产区| 亚洲激情综合| 美女久久网站| 亚洲欧美在线aaa| 欧美午夜免费| 99视频国产精品免费观看| 模特精品在线| 久久精品中文字幕一区二区三区| 国产精品乱码一区二三区小蝌蚪| 日韩视频二区| 亚洲国产99| 裸体歌舞表演一区二区| 黄网动漫久久久| 久久久久国产免费免费| 亚洲一区二区三区久久| 欧美色图五月天| 一级日韩一区在线观看| 亚洲国产欧美久久| 男人插女人欧美| 亚洲第一精品夜夜躁人人爽| 亚洲免费观看在线观看| 欧美激情视频一区二区三区免费 | 在线亚洲伦理| 欧美日韩亚洲三区| 一区二区国产日产| 亚洲精品国产欧美| 欧美激情一区二区三区成人| 国产精品视频九色porn| 亚洲免费小视频| 一区二区三区四区五区视频| 欧美日韩影院| 亚洲在线成人| 亚洲综合大片69999| 国产精品一二| 久久成人国产| 久久不射2019中文字幕| 黄色成人在线网址| 免费成人av在线| 久久尤物电影视频在线观看| 亚洲国产精品黑人久久久| 欧美高清一区| 欧美激情久久久| 一本久久综合亚洲鲁鲁| 99这里只有精品| 国产精品久久久久一区二区三区共 | 久久国产精品毛片| 精久久久久久| 欧美激情中文字幕乱码免费| 欧美激情视频在线播放| 国产精品99久久久久久久久| 亚洲香蕉在线观看| 国产一区清纯| 欧美黑人一区二区三区| 欧美日韩国产综合视频在线观看中文| 亚洲一级在线| 欧美一区二区三区啪啪| 亚洲丰满在线| 日韩午夜精品| 国产欧美日韩精品丝袜高跟鞋 | 免费亚洲网站| 一本大道久久a久久精品综合| 在线综合欧美| 国内精品**久久毛片app| 欧美激情久久久久久| 欧美日韩免费| 久久久久国内| 欧美sm重口味系列视频在线观看| 在线视频精品一| 亚洲欧美日韩国产另类专区| 在线免费精品视频| 日韩视频免费观看高清完整版| 国产久一道中文一区| 欧美大片一区二区| 欧美性一区二区| 麻豆成人在线播放| 亚洲欧美区自拍先锋| 一区在线电影| 99国产精品一区| 国内精品伊人久久久久av一坑| 亚洲激情在线观看| 国产欧美精品在线| 亚洲国产一区二区三区青草影视 | 蜜月aⅴ免费一区二区三区| 欧美精品日韩| 久久久久久有精品国产| 欧美精品色综合| 久久久久久久成人| 欧美日韩精品福利| 久久婷婷影院| 欧美性jizz18性欧美| 嫩草国产精品入口| 国产精品网曝门| 亚洲国产经典视频| 国产亚洲一区二区精品| 亚洲精品视频在线看| 狠狠色狠狠色综合人人| 一区二区三区四区五区在线 | 欧美日韩亚洲一区三区 | 日韩一区二区久久| 欧美在线短视频| 亚洲午夜性刺激影院| 浪潮色综合久久天堂| 欧美在线国产精品| 欧美日韩一区精品| 欧美二区在线| 国产一区二区三区直播精品电影| 日韩视频在线一区二区三区| 在线精品亚洲一区二区| 性欧美精品高清| 亚洲综合欧美| 欧美理论在线播放| 欧美激情中文字幕一区二区 | 日韩一级精品视频在线观看| 久久福利视频导航| 午夜日韩福利| 欧美精品v日韩精品v国产精品| 久久亚洲影音av资源网| 国产精一区二区三区| 99精品国产在热久久| 亚洲免费av片| 免费观看一级特黄欧美大片| 久久久www| 国产欧美日韩视频一区二区| 夜夜嗨av一区二区三区网站四季av | 久久久久久9| 久久精品中文字幕免费mv| 国产精品亚洲欧美| 亚洲一区二区动漫| 亚洲欧美日韩久久精品| 欧美日韩国产系列| 亚洲日韩视频| 99热在线精品观看| 欧美精品99| 亚洲开发第一视频在线播放| 亚洲精品一区二区三区99| 免费观看成人网| 欧美成人精品| 最新亚洲一区| 欧美成人中文字幕| 亚洲国产精品成人精品| 亚洲欧洲日产国产综合网| 免费久久99精品国产| 欧美激情精品久久久久久变态| 亚洲电影观看| 欧美va天堂| 亚洲欧洲精品一区二区| av成人免费| 欧美三级电影精品| 亚洲午夜黄色| 久久xxxx| 樱花yy私人影院亚洲| 玖玖国产精品视频| 亚洲狠狠婷婷| 亚洲一区二区影院| 国产精品私拍pans大尺度在线| 亚洲欧美精品suv| 久久久亚洲午夜电影| 在线日韩欧美视频| 欧美激情中文字幕在线| 99精品免费视频| 欧美一区网站| 激情五月综合色婷婷一区二区| 美国十次成人| 亚洲精品专区| 午夜一级在线看亚洲| 韩国自拍一区| 欧美风情在线观看| 这里只有精品视频| 久久久福利视频|