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

loop_in_codes

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

傳遞Lua函數(shù)到C/C++中

传递Lua函数到C/C++中

问题

在Lua中,因为函数也是第一类值,所以会出现将函数作为另一个函数的参数,或者函数作 为函数的返回值。这种机制在很多地方都能代码更灵活更简洁,例如:

table.sort(table [,comp])

这里的comp就要求传入一个函数,我们在调用时,大概会有如下形式:

table.sort(t, comp) -- 直接写函数名
table.sort(t, local_comp) -- 某个局部函数
table.sort(t, function (a, b) xxx end ) -- 临时构造一个匿名函数

其中最后一种方式最为灵活,任意时候在需要的时候构造一个匿名函数。这种在Lua自身的 环境中使用,自然没有问题。但是,当我们在C/C++中注册一些函数到Lua环境中,而这些 函数也需要使用函数参数的时候,问题就出来了。

Lua本身是不支持将Lua函数作为函数参数传入C/C++的,不管这个想要传入的函数是全局的 、局部的、或者匿名的(匿名的本质上也算局部的)。一般情况下,我们唯一的交互方式, 不是传入一个函数,而是一个全局函数名。C/C++保存这个函数名,在需要回调Lua的时候, 就在Lua全局表中找到这个函数(根据函数名),然后再调用之。情况大致如下:

function lua_func () xxx end
cfunc(lua_func) -- wrong
cfunc("lua_func") -- right

我们这回的脚本模块,策划会大量使用需要回调函数的C/C++函数。显然,创建大量的全局 函数,先是从写代码的角度看,就是很伤神的。

解决

我们最终需要的方式,大概如下:

cfunc(lua_func) -- ok
cfunc(function () xxx end) -- ok
local xxx = function () xxx end
cfunc(xxx) -- ok

要解决这个问题,我的思路是直接在Lua层做一些包装。因为C/C++那边仅支持传入一个全局 函数名(当然不一定得全局的,根据实际情况,可能在其他自己构造的表里也行),也就是 一个字符串,所以我的思路就是将Lua函数和一个唯一的字符串做映射。:

function wrap (fn)
    local id = generate_id()
    local fn_s = "__callback_fn"..id
    _G[fn_s] = fn
    return fn_s
end

这个wrap函数,就是将一个函数在全局表里映射到一个字符串上,那么在使用时:

cfunc(wrap(function () xxx end))
cfunc(const char *fn_name, xxx); -- cfunc的原型

cfunc是C/C++方注册进Lua的函数,它的原型很中规中矩,即:只接收一个函数名,一个字 符串,如之前所说,C/C++要调用这个回调函数时,就根据这个字符串去查找对应的函数。 脚本方在调用时,如果想传入一个匿名函数了,就调用wrap函数包装一下即可。

一个改进

上面的方法有个很严重的问题,在多次调用wrap函数后,将导致全局表也随之膨胀。我们需 要想办法在C/C++完成回调后,来清除wrap建立的数据。这个工作当然可以放到C/C++来进行 ,例如每次发生回调后,就设置下全局表。但这明显是不对的,因为违背了接口的设计原则 ,这个额外的机制是在Lua里添加的,那么责任也最好由Lua来负。要解决这个问题,就可以 使用Lua的metamethods机制。这个机制可以在Lua内部发生特定事件时,让应用层得到通知。 这里,我们需要关注__call事件。

Lua中只要有__call metamethod的值,均可被当作函数调用。例如:

ab(1, 2)

这里这个函数调用形式,Lua就会去找ab是否有__call metamethod,如果有,则调用它。这 个事实暗示我们,一个table也可以被调用。一个改进的wrap函数如下:

local function create_callback_table (fn, name)
    local t = {}
    t.callback = fn
    setmetatable (t, {__call =  -- 关注__call
        function (func, ...) -- 在t(xx)时,将调用到这个函数
            func.callback (...) -- 真正的回调
            del_callback (name) -- 回调完毕,清除wrap建立的数据
        end })
    return t
end

function wrap (fn)
    local id = generate_func_id() -- 产生唯一的id
    local fn_s = "_callback_fn"..id
    _G[fn_s] = create_callback_table(fn, fn_s) -- _G[fn_s]对应的是一个表
    return fn_s
end

在我们的C/C++程序中,依然如往常一样,先是从_G里取出函数名对应的对象。虽然这个对 象现在已经是一个table。然后lua_call。

上面的代码是否会在原有基础上增加不可接受的性能代价?虽然我没有做过实际测试,但是 从表明看来,排除meta table在Lua里的代价,也就多了几次Lua函数调用。

最后,感叹一下,Lua里的table及metatable机制,实在非常强大。这种强大不是功能堆砌 出来的强大,而是简单东西组合出来的强大。其背后的设计思想,着实让人佩服。

4.26.2011 Update

之前的文中说“Lua本身是不支持将Lua函数作为函数参数传入C/C++的“,这句话严格来说不 正确(由某网友评论)。假设函数cfun由c/c++注册,我们是可以编写如下代码的:

cfunc(print) -- 传入Lua函数

但是问题在于,我们无法取出这个函数并保存在c/c++方。Lua提供了一些接口用于取cfunc 的参数,例如luaL_checknumber(封装lua_tonumber)。但没有类似luaL_checkfunction的 接口。Lua中的table有同样的问题。究其原因,主要是Lua中的函数没有直接的c/c++数据结 构对应。

;; END

posted on 2011-04-24 17:28 Kevin Lynx 閱讀(11591) 評(píng)論(9)  編輯 收藏 引用 所屬分類(lèi): lua

評(píng)論

# re: 傳遞Lua函數(shù)到C/C++中 2011-04-24 20:40 dourgulf

收藏,一直沒(méi)有下決心來(lái)好好學(xué)習(xí)一下LUA  回復(fù)  更多評(píng)論   

# re: 傳遞Lua函數(shù)到C/C++中 2011-04-25 11:36 oo

"Lua本身是不支持將Lua函數(shù)作為函數(shù)參數(shù)傳入C/C++的"
???

===============================================================================
test.c
===============================================================================

static int ctest(lua_State * L)
{
lua_pushstring(L, "hello");
lua_call(L, 1, 0);
return 0;
}

int main()
{
lua_State * L = luaL_newstate();
luaL_openlibs(L);
luaL_Reg funs [] = {
{"ctest", ctest},
{NULL, NULL}
};
luaL_register(L, "_G", funs);
luaL_dofile(L, "test.lua");
lua_close(L);
}
===============================================================================

===============================================================================
test.lua
===============================================================================
ctest(print)
===============================================================================
  回復(fù)  更多評(píng)論   

# re: 傳遞Lua函數(shù)到C/C++中 2011-04-25 13:19 Kevin Lynx

@oo
這句話(huà)是欠妥,3Q。不過(guò),因?yàn)樵赾/c++里沒(méi)有映射Lua函數(shù)的類(lèi)型,所以沒(méi)有辦法把傳入的print取出來(lái)。這無(wú)法滿(mǎn)足回調(diào)的需求。  回復(fù)  更多評(píng)論   

# re: 傳遞Lua函數(shù)到C/C++中 2011-05-08 03:44 thelONE

"在我們的C/C++程序中,依然如往常一樣,先是從_G里取出函數(shù)名對(duì)應(yīng)的對(duì)象。雖然這個(gè)對(duì)象現(xiàn)在已經(jīng)是一個(gè)table。然后lua_call"

這么做的效果不好, 你可以考慮用在C++里用lua_ref引用你在lua里創(chuàng)建的函數(shù), 在調(diào)用的時(shí)候可以提高性能.  回復(fù)  更多評(píng)論   

# re: 傳遞Lua函數(shù)到C/C++中 2011-05-08 19:36 Kevin Lynx

@thelONE
有沒(méi)有做過(guò)這方面的測(cè)試?  回復(fù)  更多評(píng)論   

# re: 傳遞Lua函數(shù)到C/C++中 2013-04-21 19:32 fy

=.= 我發(fā)現(xiàn)當(dāng)個(gè)純伸手黨也挺困難的,有人指路的情況下generate_func_id神馬的都不想自己寫(xiě)啊。。。

話(huà)說(shuō)那個(gè)改進(jìn)型只是考慮了函數(shù)被調(diào)用一次,如果是比如 KeyInput 這種多次回調(diào),就完全無(wú)用了啊。

同樣,在多次回調(diào)的時(shí)候,能不能通過(guò)某種方式得到相當(dāng)于函數(shù)引用的一個(gè)全局唯一的id,這樣就不用每次通過(guò)name來(lái)lua_getglobal了?
  回復(fù)  更多評(píng)論   

# re: 傳遞Lua函數(shù)到C/C++中 2013-04-21 21:38 fy

@fy

補(bǔ)上一個(gè)自己擼出來(lái)的版本:


math.randomseed(os.time())

function generate_id(length)
local rand = ""
length = length or 13
local allchars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'

for i=1,length do
code = string.char(math.random(48, 122))
while string.find(allchars, code) == nil do
code = string.char(math.random(48, 122))
end
rand = rand .. code
end

rand = '__callback_fn_' .. rand
while _G[rand] do
rand = generate_id(length)
end
return rand
end

function wrap (fn)
local id = generate_id()
local fn_s = "__callback_fn_" .. id
_G[fn_s] = fn
return fn_s
end
  回復(fù)  更多評(píng)論   

# re: 傳遞Lua函數(shù)到C/C++中 2013-04-22 22:30 fy

@fy

由于對(duì) lua 不太了解險(xiǎn)些出了大事...
上面那個(gè)程序有時(shí)候會(huì)報(bào) lua: test.lua:12: malformed pattern (missing ']')
錯(cuò)誤,這是因?yàn)殡S機(jī)隨到了 [ 字符!
于是 string.find 就把這一個(gè)字符當(dāng)成了不完整的正則,從而導(dǎo)致錯(cuò)誤。。。

下面是修改后的版本:


function generate_id(length)
local rand = ""
length = length or 13
local allchars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

for i=1,length do
code = string.char(math.random(65, 90))
rand = rand .. code
end

rand = '_' .. rand
while _G[rand] do
rand = generate_id(length)
end

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

# re: 傳遞Lua函數(shù)到C/C++中 2013-04-24 20:00 Kevin Lynx

@fy
謝謝有價(jià)值的回復(fù)。
距離這篇博客的寫(xiě)作時(shí)間太久了,我只能簡(jiǎn)單說(shuō)明下。實(shí)際上我們項(xiàng)目中最后使用的方式是@thelONE在評(píng)論中提到的方法。即,在lua中直接傳遞函數(shù)對(duì)象(全局函數(shù)、局部函數(shù)、匿名函數(shù)),C/C++中先通過(guò)luaL_ref將這個(gè)函數(shù)對(duì)象建立索引并保存進(jìn)注冊(cè)表,在luaL_unref之前,這個(gè)函數(shù)對(duì)象由于存在“引用”所以不會(huì)被垃圾回收。那么,程序里就可以保存luaL_ref這個(gè)索引值。當(dāng)要調(diào)用這個(gè)函數(shù)時(shí),就根據(jù)該索引從注冊(cè)表中取出(大概是lua_gettable)。實(shí)際操作你可以自己查查。這種方式感覺(jué)上效率應(yīng)該會(huì)高不少,對(duì)于腳本方的使用也更自由。但是有個(gè)嚴(yán)重的問(wèn)題,就是當(dāng)我們進(jìn)行效率檢查時(shí),定位腳本不太容易,因?yàn)镃/C++這邊沒(méi)有有效的方式去標(biāo)識(shí)一個(gè)lua函數(shù)對(duì)象(當(dāng)然后面還是使用了些其他方法,例如使用debug庫(kù)獲得函數(shù)對(duì)象的位置信息)。
  回復(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>
            欧美综合激情网| 亚洲免费电影在线| 久久久激情视频| 午夜精品福利一区二区蜜股av| 欧美日韩一区二区三区在线 | 久久国产婷婷国产香蕉| 99精品热6080yy久久| 亚洲国产视频a| 亚洲国产精品一区二区第四页av| 国产精品男女猛烈高潮激情| 国产精品v日韩精品v欧美精品网站| 久久天堂国产精品| 久久精品一区二区三区不卡| 欧美一站二站| 欧美二区在线看| 欧美片在线播放| 欧美午夜免费影院| 国语精品中文字幕| 亚洲日本免费电影| 欧美一级网站| 久久这里只有精品视频首页| 99re视频这里只有精品| 中日韩在线视频| 久久免费少妇高潮久久精品99| 久久综合狠狠| 亚洲一区在线看| 欧美日韩国产综合新一区| 国产亚洲福利一区| 日韩视频在线永久播放| 久久国产一区二区| 夜夜夜久久久| 久久精品日韩| 亚洲美女少妇无套啪啪呻吟| 欧美一区1区三区3区公司| 欧美日韩国产精品一区| 激情欧美一区二区| 欧美一级免费视频| aⅴ色国产欧美| 国产精品扒开腿做爽爽爽软件| 亚洲国产精品999| 久久亚洲不卡| 久久精品最新地址| 国产日韩在线一区| 亚洲欧美视频| 一区二区三区免费在线观看| 欧美欧美天天天天操| 亚洲欧洲日本一区二区三区| 欧美凹凸一区二区三区视频| 久久精品国产v日韩v亚洲| 国产精品一区二区在线观看| 午夜天堂精品久久久久 | 亚洲二区免费| 久久久久久成人| 欧美中文在线观看国产| 国产一区二区在线免费观看| 久久久xxx| 欧美日韩高清在线观看| 亚洲欧美国产一区二区三区| 亚洲视频999| 极品av少妇一区二区| 亚洲国产老妈| 欧美性大战久久久久久久| 欧美一区二区福利在线| 免费观看成人| 欧美在线观看视频一区二区三区| 午夜在线观看免费一区| 久久综合九色欧美综合狠狠| 亚洲国产成人精品视频| 亚洲欧美精品在线观看| 亚洲人体影院| 免费成人高清| 一区二区三区久久| 欧美日韩在线观看一区二区| 久久久精品国产一区二区三区 | 欧美波霸影院| 国产精品人人做人人爽人人添| 久久久91精品国产| 国产亚洲欧美日韩日本| 91久久在线播放| 99精品国产高清一区二区| 久久视频精品在线| 免费在线成人av| 亚洲国产成人tv| 欧美区一区二区三区| 99精品国产在热久久下载| 亚洲伊人色欲综合网| 国产日产精品一区二区三区四区的观看方式 | 亚洲精品久久久久久下一站| 国产一区美女| 欧美一级理论片| 免费欧美在线| 亚洲欧美日韩精品久久久| 欧美午夜片在线观看| 性久久久久久| 亚洲高清视频一区| 一区二区三欧美| 国产日韩欧美精品| 午夜在线播放视频欧美| 欧美三级电影精品| 亚洲在线成人精品| 亚洲第一福利社区| 欧美一区二区在线免费观看| 韩国在线一区| 欧美色视频日本高清在线观看| 香蕉久久国产| 一本大道久久a久久精二百| 久久高清国产| 日韩亚洲成人av在线| 狠狠色2019综合网| 国产精品vvv| 国产精品久久久999| 欧美日韩国产一区| 久久中文字幕导航| 亚洲专区在线视频| 一区二区三区欧美在线观看| 欧美国产视频日韩| 久久一区二区视频| 久久精品中文字幕免费mv| 亚洲调教视频在线观看| 亚洲国产欧美日韩| 99在线|亚洲一区二区| 亚洲欧洲一区二区天堂久久 | 国内在线观看一区二区三区| 欧美久久婷婷综合色| 欧美日韩亚洲一区二区三区在线观看| 免费不卡中文字幕视频| 午夜欧美视频| 欧美国产亚洲精品久久久8v| 久久尤物电影视频在线观看| 欧美一区精品| 久久噜噜噜精品国产亚洲综合| 午夜在线一区二区| 久久免费精品日本久久中文字幕| 欧美日韩一区二区视频在线观看| 久久成人免费网| 老牛嫩草一区二区三区日本| 欧美成熟视频| 国产在线精品自拍| 亚洲毛片在线免费观看| 亚洲欧美日韩第一区| 久久亚洲欧洲| 亚洲男人第一av网站| 欧美成人亚洲成人| 国产欧美日韩一级| 中文日韩电影网站| 欧美激情欧美激情在线五月| 亚洲欧美日韩在线播放| 欧美另类久久久品| 在线精品视频一区二区| 久久高清福利视频| 亚洲欧美日韩国产中文 | 免费亚洲视频| 亚洲欧美日韩国产精品| 欧美日韩一区二区三区| 亚洲精品久久久一区二区三区| 欧美一区国产在线| 亚欧美中日韩视频| 国产精品免费小视频| 欧美一区二区在线看| 欧美亚洲在线播放| 国产麻豆综合| 欧美aⅴ99久久黑人专区| 欧美一区二区视频97| 今天的高清视频免费播放成人| 亚洲欧美一区二区三区在线| 亚洲午夜激情在线| 国产自产高清不卡| 欧美国产激情二区三区| 欧美成人中文字幕| 宅男噜噜噜66一区二区| 亚洲视频每日更新| 国产一区二区丝袜高跟鞋图片| 久久精品国产一区二区三| 久久国产免费| 一本久久a久久精品亚洲| 99re这里只有精品6| 日韩视频一区二区三区在线播放| 欧美亚洲第一页| 久久一区精品| 国产精品区二区三区日本| 欧美~级网站不卡| 国产精品www| 亚洲卡通欧美制服中文| 韩国福利一区| 欧美一区二区三区视频免费| 一区二区三区四区国产| 久久久久欧美| 久久久最新网址| 欧美午夜精品电影| 91久久精品国产91久久| 精品成人一区二区三区| 亚洲欧美999| 性欧美在线看片a免费观看| 欧美美女操人视频| 亚洲欧洲日本mm| 日韩午夜黄色| 欧美日本国产精品| 亚洲伦理久久| 亚洲性人人天天夜夜摸| 国产精品劲爆视频|