lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

----- Original Message -----
From: Oliver Schmidt
Date: 2/5/2010 12:10 PM

On Friday 05 February 2010, Joshua Jensen wrote:

LuaPlus (http://luaplus.org) lets you hold onto a Lua object within a
C++ object:

LuaObject myDataObj = state->GetGlobal("MyData");
LuaObject valueObj = myDataObj["Value"];

The Lua data is stored within the LuaObject itself and does not need the
Lua stack.

As I can see from LuaPlus, the LuaObject class looks like:

     class LuaObject
     {
     public:
         ....
     private:
         LuaObject* m_next;  // only valid when in free list
         LuaObject* m_prev;  // only valid when in used list
     #if defined(BUILDING_LUAPLUS)
         lua_TValue m_object;
     #else
         LP_lua_TValue m_object;
     #endif
         LuaState* m_state;
     };

How does this work?  So objects of this class are holding directly the lua_TValue from the Lua
virtual machine?
By storing the lua_TValue locally, it provides the fastest possible access to the data being stored. It is as if LuaPlus's C++ LuaObjects extend the Lua stack into C++ objects. 
How does this interfere with the Lua garbage collector?
The LuaObjects are marked during the garbage collector's markroot() and atomic() runs. 
I guess the Lua core must have been modified to get this working?
Yes, although the modifications are less than what you might expect. With just a cursory glance, all I really need to pull this off is a user garbage collection callback called at the markroot() and atomic() calls. There might be more; I'd have to do a more detailed analysis. 
In you implementation: would have been the existence of something like my
function lua_unuse be useful?

It seems that your implementation does also use a lot of internals of the Lua
core. Do you think that some modifications to the official public Lua C-API
could be useful to make integration with the C++ object system (i.e.
constructor/destructor mechanism) easier?
What I want to do is fix luaL_ref() to be fast. I don't really want to modify the Lua core, but I want access to saved off Lua values to be faster than it currently is. Lua 4.0 or 4.1, I believe, had a more efficient lua_ref() for my usage patterns. If luaL_ref() was more efficient, then a LuaPlus::LuaObject() would just wrap that.
That doesn't directly answer your question, but it does show that I'd like some modifications to be able to use a standard Lua core with the C++ classes I maintain. 

Josh