从C ++将已经存在的对象返回给Lua

Question

In C++, say I have a class that creates a binary tree like structure and I use it something like this:

CTreeRoot* root = new CTreeRoot(/* whatever */);
CNode* leftNode = root->getLeftNode();
CNode* rightNode = root->getRightNOde();

leftNode->doSomething();
rightNode->doSomething();

// etc

And assume that the left and right nodes have their own left and right nodes (hence, a binary tree). Now I want to expose this to Lua ( not using luabind) so I can do the same kind of thing:

local root = treeroot.new(/* whatever */)
local left = root:getLeftNode()
local right = root:getRightNode()

left:doSomething();
right:doSomething(); 

I've gotten most of it to work. However, for the getLeftNode() and getRightNode() methods, I'm pretty sure I'm doing it "wrong". Here is how I'm implementing getLeftNode() in C++ for example:

int MyLua::TreeRootGetLeftNode(luaState* L)
{
    CTreeRoot* root = (CTreeRoot*)luaL_checkudata(L, 1, "MyLua.treeroot");
    CNode* leftNode = root->getLeftNode();

    if (leftNode != NULL)
    {
        int size = sizeof(CNode);

        // create a new copy of the CNode object inplace of the memory Lua
        // allocated for us
        new ((CNode*)lua_newuserdata(L,size)) CNode((const CNode&)*leftNode);
        lua_setmetatable(L, "MyLua.treenode");
    }
    else
    {
        lua_pushnil(L);
    }

    return 1;
}

I cast the userdata back to a CTreeRoot object, call getLeftNode(), make sure it exists and then (here's the "wrong part") I create another userdata data object with a copy constructor copying the object I want to return.

Is this "standard practice" for this type of scenario? It seems like you would want to avoid creating another copy of the object since what you really want is just a reference to an already existing object.

It sounds like this would be the perfect place for lightuserdata since I don't want to create a new object, I would be happy returning the object that already exists. The problem, though, is that lightuserdata has no meta table so the objects would be useless to me once I got them back. Basically, I want to do something like:

int MyLua::TreeRootGetLeftNode(luaState* L)
{
    CTreeRoot* root = (CTreeRoot*)luaL_checkudata(L, 1, "MyLua.treeroot");
    CNode* leftNode = root->getLeftNode();

    if (leftNode != NULL)
    {
        // "WRONG" CODE BUT SHOWS WHAT I WISH I COULD DO
        lua_pushlightuserdata(L, (void*)leftNode);
        lua_setmetatable(L, "MyLua.treenode");
    }
    else
    {
        lua_pushnil(L);
    }

    return 1;
}

Can someone please tell me how I can have my MyLua::TreeRootGetLeftNode method return to Lua a copy of the object that already exists in such a way that I can use that object as an 'object' in Lua?

Answer 1

There are two levels of memory optimization that can be performed here. In your first functional-but-inefficient solution, when the user calls getLeftNode() , it has to create a copy of the CNode in order to store it in the Lua userdata. Furthermore, each time the user calls getLeftNode() repeatedly on the same tree, it will keep creating new userdata to represent the CNode even though it has have been created previously.

In the first level of optimization, you can memoize this call so that each time the user requests for the same subtree, you can simply return the userdata that was originally created instead of copying and constructing another userdata to represent the same thing. There are 3 approaches to this though, depending on whether you want to modify the Lua interface, alter the C++ implementation, or just bite the bullet.

• The MyLua.treenode userdata currently contains the actual data of a CNode object. This is unfortunate, however, because that means whenever you create a CNode object, you have to use placement new to store it into the memory allocated by Lua immediately upon creation. What is probably better is to simply store a pointer instead ( CNode* ) in the userdata for MyLua.treenode . This does require you to modify the Lua interface for MyLua.treenode so that it will now consider its data as a pointer to a CNode object.

• If you would rather store the CNode data in the MyLua.treenode userdata directly, then you will have to make sure that when you create your CTreeRoot , it would use placement new to construct CNode s from the memory allocated by Lua each time (or perhaps you can use the allocator pattern used in the C++ standard library?). This is less elegant however as your CNode implementation now depends on the Lua runtime, and I don't recommend this.

• If neither of the above solutions are appropriate, then you'll just have to make a copy whenever you return a subnode, although you can still improve the efficiency for repeated calls on the same node by keeping track of whether you have created the same userdata before (using a Lua table, for example).

In the second level of optimization, you can further save memory by making your copied subtree to be a weak reference to a fragment of the original tree. This way, whenever you copy a subtree, you are merely creating a pointer to a part of the original tree. Or, you can use a strong reference if you want your subtree to persist even after the original tree is destroyed, but then you'll have to go into the gory details of reference-counting. In either case, this optimization is purely on the C++ level and is not related to the Lua interface, and judging from your code I assume you are already using weak references ( CNode* ).

Note: Light userdata are probably best avoided except for use in the internal implementation. The reason being that light userdata are essentially equivalent to C pointers and thus can point to just about anything. If you expose light userdata to Lua code, you will have no idea where the light userdata may have come from or what type of data it contains, using it poses a security risk (as well as the possibility to segfault your program). An appropriate way to use light user data would be to use it as an index of a Lua lookup table stored in the Lua registry, which can be used to implement the memoization that was mentioned earlier.