假设我有一个这样的课程:
class A
{
public:
A(){}
~A(){}
};
通过Luabind将它暴露给Lua:
module(luaState)
[
class_<A>("Foo")
.def(constructor<>())
];
最后在这样的脚本中实例化它:
A = Foo();
此时A的实际“存在状态”是什么?
它在堆中的某个地方,并且lua在某个地方保留了对它的引用? (或luabind :: object?)
我觉得它只能是一个指针,如新的或同等的。
但是,我可以将函数绑定到接受引用的lua,例如lua_doSomething(A & a)
,最后会有一个实际的引用。
我知道这很可能只是luabind将a
传递给*a
,但我不知道是否会发生这种情况。
我问这个的原因是要更好地理解和预测在脚本中实例化的对象的生命周期。
那,如果不是像上面那样将课程暴露给lua,我不确定所有权或生命周期是否会发生变化,我会这样做:
A * lua_CreateA()
{
return new A();
}
module(luaState)
[
class_<A>("Foo")
];
module(luaState)
[
def("createA",&lua_CreateA)
];
并使用它
A = createA();
根据我目前所理解的逻辑,这个案例需要我进行清理,因为我是分配一个新对象的人,除非对于luabind的这样的赋值与使用绑定的构造函数一样。< / p>
简而言之,我真的很困惑对象的生命周期和这里的东西...... 我搜索了与此相关的关键字,但我只是得到了类似的东西 http://www.gamedev.net/topic/525692-luabind-ownership-and-destruction/
这不是我真正想知道的。 我想了解在幕后处理事情的具体方式,包括分配,实例化,生命周期以及所有这些。
答案 0 :(得分:5)
Luabind的对象生命周期非常简单。你不需要了解Luabind在内部做什么的血腥细节。
Lua直接拥有由 Lua创建的对象。因此,如果在Lua中使用构造函数语法分配对象,则该对象由Lua拥有。当Lua中不再引用该对象时,Lua GC将收集它。
如果Lua通过任何其他方式获取对象的引用,那么除非您使用Luabind的采用策略专门转移所有权,否则Lua 不拥有该对象。因此,如果您绑定一个将对象返回给Lua的函数,这样您现在可以期望Lua决定该对象何时存活,那么您需要使用adopt策略。
最后一段仅适用于实际引用(返回指针和引用类型)。如果给Lua一个对象的副本(通过非引用或指针返回值),那么Lua将拥有该对象的副本。