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

loop_in_codes

低調做技術__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

實現自己的LUA綁定器-一個模板編程挑戰

實現LUA綁定器

author : Kevin Lynx

Preface


    當LUA腳本調用我們注冊的C函數時,我們需要逐個地從LUA棧里取出調用參數,當函數返回時,又需要一個一個地往LUA
棧壓入返回值,并且我們注冊的函數只能是int()(lua_State*)類型。這很不方便,對于上層程序員來說更不方便。
    因此我們要做的是,實現一個綁定器,可以把任意prototype的函數綁定到LUA腳本當中,并且封裝取參數和壓返回值時
的諸多細節。
    確實,世界上已經有很多庫做了這件事情。但是,我們這里的需求很簡單,我們只需要綁定函數,而不需要綁定C++類之
類的東西,自己實現的才是輕量級的。

What we usually do

    先看下我們平時是怎么做這些事的。首先注冊函數很簡單:

    lua_pushcfunction( L, to_string );
    lua_setglobal( L,
"tostr"
);


    然后是func的具體處理:

    /** 假設to_string在腳本中的原型是: string ()( number ) */
   
static int to_string( lua_State *L )
   
{
       
static char buf[512
];
       
/* 從LUA棧中取參數 */

       
int n = (int)lua_tonumber( L, -1 );
        sprintf( buf,
"%d"
, n );
       
/* 壓入返回值 */

        lua_pushstring( L, buf );
       
return 1;
    }


    這是個簡單的例子,目的是展示我之前說的局限性,以及,恩,丑陋性。


How

    要讓事情變得優美,我們就得隱藏丑陋。
    首先,我們看看如何改進to_string的處理,使其看起來干凈。最直接也是最通用的做法是,我們自己做一個粘合層,
充當LUA與應用層之間的粘合劑。也就是說,LUA直接回調的不再直接是應用層的函數,而是我們實現的這一層中的函數,
我們的函數整理調用參數,然后回調到上層函數,上層返回后,我們收集上層的返回值,然后整理給LUA,最后返回。
    這就是思路,具體實現時更為有趣。

Implementing...

    直覺告訴我,我需要使用C++模板來實現。模板和宏都是個好東西,因為它們是泛性的,它們給程序員帶來自動性。
    另一個直覺告訴我,盡量不要讓上層保存任何東西。通過模板的實例化,編譯器已經為我們添加了很多東西,我也不
想讓上層理會我太多。
    因為,我們至少需要保存上層的函數指針(我們暫時只考慮C式的函數),我們至少還需要一個粘合層函數用以被LUA
直接回調,所以,我得到了以下類模板:

    template <typename Prototype>
   
class lua_binder
   
{
   
public
:
        typedef Prototype func_type;
   
public
:
       
static int adapter( lua_State *
L )
       
{
           
return 0
;
        }
 

   
public
:
       
static
func_type _func;
    }
;
    template
<typename Prototype> typename lua_binder<Prototype>::func_type lua_binder<Prototype>::_func = 0
;


    這樣,泛化了Prototype后,lua_binder可以保存任意原型的函數指針。例如:

 

typedef lua_binder<const char*(int)> binder_type;

  
    借助于模板技術,即使上層只是這樣一個簡單的看似不會產生任何代碼的typedef,實際上也會產生出一個static的
函數指針變量:_func。

    這個時候,我們也該考慮下注冊函數部分了。注意,事實上我們總共需要干兩件事:封裝粘合層函數、封裝注冊函數
部分。同樣,我們得到一個最直觀的注冊函數模板:

 

    template <typename binder_type>
   
void lua_bind( lua_State *L, typename binder_type::func_type func, const char *name )
   
{
        binder_type::_func
=
func;
        lua_pushcfunction( L, binder_type::adapter );
        lua_setgloabl( L, name );
    }


    為什么模板參數是binder_type而不是Prototype?(最直接的想法可能會想到Prototype)因為我們需要獲取func_type
以及最重要的:設置_func的值!綜合起來,lua_bind函數主要作用就是接受用戶層函數指針,并相應的將粘合層函數注冊
到LUA中。注意,lua_pushcfunction注冊的是binder_type::adapter函數。

    那么,理論上,我們現在可以這樣注冊一個函數:

    typedef lua_binder<const char*(_cdecl*)(int)> binder_type;
    lua_bind
<binder_type>( L, to_string, "tostr"
);


    (這個時候to_string為:const char* to_string( int ) )


處理函數參數的個數

    事情遠沒有我們想象的那么簡單。adapter函數中毫無實現,重要的是,該如何去實現?我們面對的首個問題是:上層
函數參數個數不一樣,那么我們的adapter該調用多少次lua_to*去從LUA棧中獲取參數?
    解決該問題的辦法是,恩,很笨,但是這可以工作:為不同參數個數的函數都實現一個對應的adapter。沒有參數的函數對
應一個adapter,一個參數的函數對應另一個adapter,依次類推。
    (穿插一下:ttl(tiny template library)庫中使用了一個很強大的宏技術,可以自動生成這些代碼,但是具體原理
我不懂。所以只能使用這個笨辦法了。)
    這樣,我們就需要區分不同參數個數的函數原型。很顯然,我們需要改進lua_binder。行之有效的技術是:模板偏特化。
改進后的lua_binder類似于:

    template <typename Prototype>
   
class lua_binder;

    template
<typename R, typename P1>

   
class lua_binder<R ( P1 )>
   
{
   
public
:
        typedef R result_type;
        typedef P1 p1_type;
        typedef result_type (
*
func_type)( P1 );
   
public
:
       
static int adapter( lua_State *
L )
       
{
           
return 0
;
        }

   
public:
       
static
func_type _func;
    }
;
    template
<typename R, typename P1>
 
    typename lua_binder
<R( P1 )>::func_type lua_binder<R( P1 )>::_func = 0
;

   
//



    lua_binder主體已經是一個單純的聲明而已,它的諸多特化版本將分別對應0個參數,1個參數,2個參數等。例如以上
列舉的就是一個參數的偏特化版本。

Now, we can try ??

    那么,我們現在是否可以寫下諸多的lua_to*函數去獲取參數了?你覺得可以嗎?假設現在要獲取棧頂第一個參數,你
該調用lua_tonumber還是lua_tostring?
    問題就在于,我們并不知道該調用哪個函數。
    解決辦法是:根據不同的參數類型,調用對應的lua_to*函數。
    不同的類型擁有不同的行為,這一點讓你想起什么?那就是模板世界里的type traits,類型萃取。我想,完成本文的
綁定器,更多的是對你模板編程能力的考驗。
    lua_to*系列函數是有限的,因此我們也只需要實現幾個類型的行為即可。我們這個時候的目的就是,根據不同的類型,
調用對應的lua_to*函數。例如,對于number(int, long, double, float, char等等),我們就調用lua_tonumber。
    于是得到:

    template <typename _Tp>
   
struct param_traits
   
{
       
static _Tp get_param( lua_State *L, int
index )
       
{
           
return static_cast<_Tp>
( lua_tonumber( L, index ) );
        }

    }
;

    template
<>

   
struct param_traits<const char*>
   
{
       
static const char *get_param( lua_State *L, int
index )
       
{
           
return
lua_tostring( L, index );
        }

    }
;
   
//others



    param_traits主體處理所有的number(因為number類型太多,也許concept可以解決這個問題),其他特化版本處理其他
類型。這樣,在adapter里,就可以根據參數類型獲取到相應的參數了,例如:

    P1 p1 = param_traits<P1>::get_param( L, -1);
    到這個時候,我們的adapter函數變為:(以一個參數的函數舉例)

    static int adapter( lua_State *L )
   
{
        p1_type p1
= param_traits<p1_type>::get_param( L, -1
);
        _func( p1 );

       
return 0
;
    }
 


And how about the result ??

    是的,我們還需要處理函數返回值。我們暫時假設所有的函數都只有一個返回值。這里面對的問題同取參數一樣,我
們需要根據不同的返回值類型,調用對應的lua_push*函數壓入返回值。
    同樣的type traits技術,你應該自己寫得出來,例如:

    template <typename _Tp>
   
struct return_traits
   
{
       
static void set_result( lua_State *
L, lua_Number r )
       
{
            lua_pushnumber( L, r );               
        }

    }
;
    template
<>

   
struct return_traits<const char*>
   
{
       
static void set_result( lua_State *L, const char *
r )
       
{
            lua_pushstring( L, r );
        }

    }
;


    到這個時候,我們的adapter函數基本成型了:

    static int adapter( lua_State *L )
   
{
        p1_type p1
= param_traits<p1_type>::get_param( L, -1
);
        result_type r
=
_func( p1 );
        return_traits
<result_type>
::set_result( L, r );
       
return 0
;
    }
 


The last 'return' ???

    最礙眼的,是adapter最后一行的return。LUA手冊上告訴我們,lua_CFunction必須返回函數返回值的個數。我們已經
假設我們只支持一個返回值,那么,很好,直接返回1吧。
    關鍵在于,C/C++的世界里還有個關鍵字:void。是的,它表示沒有返回值。在用戶層函數返回值為void類型時(原諒
這矛盾的說法),我們這里需要返回0。
    你意識到了什么?是的,我們需要根據返回值類型是否是void來設置這個return的值:1或者0。又是個type traits的
小技術。我想你現在很熟悉了:

    template <typename _Tp>
   
struct return_number_traits
   
{
       
enum

       
{
            count
= 1

        }
;
    }
;
    template
<>

   
struct return_number_traits<void>
   
{
       
enum

       
{
            count
= 0

        }
;
    }
;


    于是,我們的adapter變為:

    static int adapter( lua_State *L )
   
{
        p1_type p1
= param_traits<p1_type>::get_param( L, -1
);
        result_type r
=
_func( p1 );
        return_traits
<result_type>
::set_result( L, r );
       
return return_number_traits<result_type>
::count;
    }





Is everything OK?

    我很高興我能流暢地寫到這里,同樣我希望我不僅向你展示了某個應用的實現,而是展示了模板編程的思想。
    但是,問題在于,當你要注冊一個返回值為void的函數時:

    typedef lua_binder<void(int)> binder_type;
    lua_bind
<binder_type>( L, my_fn, "fn"
);


    你可能會被編譯器告知:非法使用void類型。
    是的,好好省視下你的代碼,當你的binder_type::result_type為void時,在adapter函數中,你基本上也就寫下了
void r = something 的代碼。這是個語法錯誤。

    同樣的問題還有:當返回值是void時,我們也沒有必要調用return_traits的set_result函數。
    我想你覺察出來,又一個type traits技術。我們將根據result_type決定不同的處理方式。于是,我寫了一個caller:

    template <typename _Tp>
   
struct caller
   
{
       
static void call( lua_State *L, p1_type &
p1 )
       
{
            result_type r
=
_func( p1 );
            return_traits
<result_type>
::set_result( L, r );
        }

    }
;

    template
<>

   
struct caller<void>
   
{
       
static void call( lua_State *L, p1_type &
p1 )
       
{
            _func( p1 );
        }

    }
;


    caller將根據不同的返回值類型決定如何去回調_func。比較遺憾的是,我們需要為每一個lua_binder編寫這么一個
caller,因為caller要調用_func,并且_func的參數個數不同。
    那么現在,我們的adapter函數變為:

    static int adapter( lua_State *L )
   
{
        P1 p1
= lua::param_traits<P1>::get_param( L, -1
);
        caller
<result_type>
::call( L, p1 );
       
return return_number_traits<result_type>
::count;
    }


END

    最后一段的標題不帶問號,所以這就結束了。下載看看我的代碼吧,為了給不同參數個數的函數寫binder,始終需要
粘貼復制的手工勞動。
    值得注意的是,在最終的代碼里,我使用了
以前實現的functor,將函數類型泛化。這樣,lua_binder就可以綁定類
成員函數,當然,還有operator()。

    開源代碼某個時候還需要勇氣,因為開源意味著你的代碼會被人們考驗。不過我對我代碼的風格比較自信。:D

    下載完整的lua_binder

posted on 2008-08-13 09:33 Kevin Lynx 閱讀(7015) 評論(15)  編輯 收藏 引用 所屬分類: c/c++lua

評論

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2008-08-13 09:47 dophi

kevin哥哥真厲害啊~  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2008-08-13 22:45 陳梓瀚(vczh)

根據經驗,開源之后,很少人會真的給你反饋什么。特別是在這里。  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2008-08-14 15:29 白云哥

模板用的很精彩,學習  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰[未登錄] 2008-08-14 22:52 清風徐來

nice work  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰[未登錄] 2008-08-17 23:04 Gohan

從你的文章中了解到了類型萃取,又是一個不小的收獲。  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2008-09-11 19:32 czc

謝謝共享代碼,有兩個疑問:

1) 文中寫道:

typedef lua_binder<const char*(int)> binder_type;

借助于模板技術,即使上層只是這樣一個簡單的看似不會產生任何代碼的typedef,實際上也會產生出一個static的 函數指針變量:_func。

=================================================
如果只是用 typedef 定義一個類型而沒有使用的話是不會產生任何代碼的。上面的那句 typedef 編譯器不會為 _func 分配存儲空間,我為此還特意寫了個簡單程序驗證了一下。或者這里是指別的意思?

2) _func 被聲明為靜態類型,意味著每種函數類型只能bind一個實例函數?如果要bind 多個同類型的函數,那么只有最后被bind的可以被調用,前面的被后面的覆蓋了。 比如在你的測試程序里再注冊一個函數 void my_fun_2(), 在 test.lua 中調用

a = fn()
a = fn_2()

結果會打印出兩個 my_fn_2, 而不是一個my_fn, 一個my_fn_2


  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2008-09-12 09:28 Kevin Lynx

@czc
非常高興有人可以給我提出如此寶貴的意見!我覺得很少有人會把我寫的東西認真讀過,甚至相關代碼。

1)我覺得你是對的,我認為只要類模板被實例化,就相當于產生了一個類,那么就會產生這個static變量。但是typedef很可能沒有實例化類模板,所以我覺得你是對的,但是如何去證明這一點?

2)你說的完全正確。當lua_binder被用于實際項目時,我也發現了這個問題,所以最后我只得用一個ID去區分這些binder:
template <typename Prototype, long id>
class lua_binder;
上層代碼就不得不自己提供一個唯一的ID,很丑陋,但是我沒有想到優雅的解決辦法,不知道你有沒有什么看法?
  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2008-12-25 12:12 天堂的隔壁

似乎沒有考慮大量參數是數據結構的情況?
不過思路已經很有啟發作用了,3ks  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2009-02-27 16:19 劍神一笑

先鼓勵下樓主的共享精神 :-)
不過這樣的實現自己研究玩還可以,但是實際項目中基本上不會用到。
原因很簡單,違反了kiss原則,在我們這些UNIX程序員的眼中,你舉的第一個“丑陋”的例子才是美的,因為項目中其它成員看到,也都很容易理解代碼。
C++及模板都是強大的工具,但也容易做出過度設計  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2009-02-28 14:54 Kevin Lynx

@劍神一笑

你說的有道理。我也越來越喜歡UNIX的東西了。:)
  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2010-04-12 00:05 anonymous

原則就是用來違反的,不違反原則就不能進步。  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2010-05-06 14:10 小時候可靚了

來頂一個哦!  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2012-08-31 10:10 asdf

對于bool, BOOL, BOOLEAN, 請問樓主如何解決……  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2013-09-12 17:06 yzm

樓主屌爆了  回復  更多評論   

# re: 實現自己的LUA綁定器-一個模板編程挑戰 2015-04-23 11:50 yk

@Kevin Lynx

為何要typedef lua_binder呢?

binder中的共性已經很好的抽象到adapter里面了,那么個性完全可以由成員變量來體現吧?

直接辦法是去掉static,讓functor直接成為binder的一個成員
然后bind的時候不在傳static那個指針了,binder定義一個對象出來,把這個對象傳給bind

這么做不知道行不行?  回復  更多評論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美成人一品| 久久精品99久久香蕉国产色戒| 一本久道久久久| 蜜臀av在线播放一区二区三区| 亚洲黄页一区| 国产亚洲一级高清| 欧美日韩成人一区二区三区| 性欧美大战久久久久久久免费观看| 久久综合九色综合欧美就去吻| 欧美一区二区三区日韩| 欧美日韩精品一区视频| 久久久爽爽爽美女图片| 亚洲精品精选| 亚洲精品久久久一区二区三区| 影音国产精品| 在线播放国产一区中文字幕剧情欧美| 免费成人激情视频| 午夜国产一区| 欧美一区二区三区四区高清| 欧美一区二视频| 午夜精品一区二区三区四区| 午夜久久一区| 久久久久久尹人网香蕉| 另类综合日韩欧美亚洲| 欧美激情按摩| 国产精品99久久久久久久久久久久 | 久久久久久久久久久久久久一区| 欧美中文字幕不卡| 欧美激情亚洲| 国产目拍亚洲精品99久久精品| 国产一区日韩二区欧美三区| 亚洲人成人99网站| 亚洲欧美视频| 亚洲第一精品在线| 在线视频欧美日韩精品| 久久久午夜视频| 国产精品网站在线观看| 亚洲人成人77777线观看| 久久蜜桃av一区精品变态类天堂| 亚洲激情av| 午夜精品久久久久影视 | 午夜精品福利在线观看| 免费在线播放第一区高清av| 欧美一区二区三区在线免费观看| 久久久爽爽爽美女图片| 国产精品美女久久久免费| 亚洲电影中文字幕| 久久婷婷人人澡人人喊人人爽| 1204国产成人精品视频| 久久99在线观看| 久久成人人人人精品欧| 欧美激情在线观看| 一本色道久久综合亚洲精品小说| 最新日韩av| 久久精品国产99精品国产亚洲性色| 欧美人与性动交a欧美精品| 亚洲国产精品免费| 欧美77777| 欧美不卡激情三级在线观看| 日韩亚洲在线| 亚洲一区精品电影| 伊人色综合久久天天| 欧美福利精品| 欧美视频中文字幕在线| 亚洲欧美精品伊人久久| 久久久久9999亚洲精品| 亚洲国产日韩一区| 亚洲欧美日韩一区在线| 亚洲经典三级| 欧美一区二区视频在线观看2020| 亚洲国产精品久久久久| 在线性视频日韩欧美| 亚洲激情成人网| 亚洲视频在线观看免费| 永久域名在线精品| 欧美伊人久久久久久午夜久久久久| 亚洲人成毛片在线播放| 久久成人一区| 久久se精品一区精品二区| 欧美天天视频| 亚洲一区二区在线视频| 在线亚洲精品| 国产精品丝袜91| 99pao成人国产永久免费视频| 中日韩视频在线观看| 亚洲黄色免费电影| 亚洲欧美一区二区原创| 亚洲专区在线视频| 欧美日韩一卡二卡| 亚洲欧美日韩精品久久亚洲区 | 亚洲一区尤物| 日韩午夜精品视频| 久久综合色婷婷| 亚洲国产日日夜夜| 亚洲视屏在线播放| 国产精品免费观看在线| 午夜精品久久| 你懂的视频一区二区| 亚洲青涩在线| 欧美精品www在线观看| 亚洲最新视频在线播放| 亚洲无人区一区| 久久嫩草精品久久久久| 亚洲欧洲一二三| 欧美日韩精品一区二区三区四区| 亚洲视频香蕉人妖| 蜜桃久久av一区| 一个色综合导航| 国产精品美女| 欧美人与禽猛交乱配视频| 亚洲一区三区电影在线观看| 欧美护士18xxxxhd| 欧美中文日韩| 亚洲欧美日韩国产一区二区三区| 久久女同互慰一区二区三区| 一级成人国产| 亚洲人成网站在线播| 欧美成人免费全部| 女人香蕉久久**毛片精品| 欧美一级二级三级蜜桃| 亚洲精美视频| 国产一区清纯| 国产精品久久久久久久久果冻传媒 | 亚洲欧洲另类| 久久福利视频导航| 亚洲男人的天堂在线观看| 亚洲美女av黄| 亚洲精品欧美精品| 99热在这里有精品免费| 一本色道久久综合亚洲精品不卡 | 欧美 日韩 国产 一区| 亚洲综合导航| 亚洲欧美bt| 久久精品一二三| 欧美中文字幕| 亚洲国产一区二区三区在线播| 欧美国产国产综合| 亚洲欧洲日韩女同| 亚洲天堂网在线观看| 亚洲一区综合| 另类天堂av| 欧美日韩美女在线观看| 国产伦精品一区二区三区高清版 | 久久久99久久精品女同性| 亚洲国产成人精品久久| 国产精品成人观看视频免费| 欧美日韩国产一区二区三区地区 | 亚洲免费视频网站| 久久先锋影音av| 亚洲激情av| 久久精品一二三| 亚洲美女精品成人在线视频| 欧美一区二区高清| 欧美日韩欧美一区二区| 国产综合婷婷| 亚洲一区二区三区在线播放| 亚洲国产成人高清精品| 午夜欧美精品久久久久久久| 欧美日韩不卡一区| 激情小说另类小说亚洲欧美| 欧美一区二区三区免费视| 亚洲毛片在线观看| 免费影视亚洲| 在线观看亚洲精品| 久久亚洲欧美国产精品乐播| 亚洲欧美日韩一区二区三区在线观看 | 久久精品国产清高在天天线| 欧美日韩中文字幕精品| 这里只有精品在线播放| 亚洲成人在线网| 欧美成人免费视频| 一本久道久久综合婷婷鲸鱼| 一区二区三区你懂的| 国产精品日韩欧美一区| 久久激情综合网| 久久精品视频免费观看| 亚洲国产精品女人久久久| 亚洲国产免费看| 国产精品久久久免费| 久久久青草青青国产亚洲免观| 久久久久久久999| 亚洲成人在线网| 亚洲一区bb| 亚洲精品在线观看免费| 亚洲一二三四久久| 永久免费精品影视网站| 9久草视频在线视频精品| 国产精品久久一卡二卡| 久久久91精品| 亚洲国产影院| 亚洲午夜精品在线| 亚洲第一区在线观看| 亚洲天堂网站在线观看视频| 亚洲人成免费| 美女国内精品自产拍在线播放| 久久国产成人| 国产精品久久二区二区| 欧美成人自拍| 亚洲欧美国产精品桃花| 亚洲国产欧美一区二区三区同亚洲|