lua-users home
lua-l archive

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

On Friday 05 February 2010, pan shizhu wrote:
> What do you mean by "C++ function"? if you mean a "C++ function with
> the prototype int foobar(lua_State *L);" then there won't be your
> problem:

I thought of something like this:

LuaVar f(LuaVar x, const char* str)
   LuaVar rslt;
   if (x.isTable()) {
       LuaVar v = x[str];
       rslt = ...
   } else {
   return rslt;

int main(int argc, char** argv)
    LuaVar x = ...
    while (...) {
        LuaVar y = f(x, argv[i])
        if (y.isString()) {

Of course the above code would not be as performant as if you manage 
the Lua stack manuelly via lua_push..., lua_replace etc. But you can 
use the C++ LuaVar objects to write easy readable C++ code that can 
integrate Lua objects with other C++ code and for some use cases
the performance lack of a automatically managed stack indices is
not as relevant as the readability of the code.

> Generally, I think using C++ variables to represent lua stack is a bad
> idea. At least it is a totally different design. Lua is designed so
> that you should never need to represent variables in your host program
> language. 

But you need some kind of stack slots indices in the host program

> Since the stack may change after any lua_ function or lua
> native function. your representation is invalid after that.

Of course you can break the stack indices in LuaVar objects
by using some Lua API calls directly. This can also happen
if you incorrectly use some Lua API calls by mistake and
get confused with manually stack management.

C++ objects of type LuaVar can be used to represent a kind of local
variable on the stack. LuaVar objects should only be used on the
C++ stack. If I want to store references to Lua objects for 
longer lifetime into C++ objects on the heap, I would use the 
Lua registry.

Of coure one could build the class LuaVar such that every local 
C++ variable holding a reference to a Lua object uses the Lua 
registry. This means a registry table lookup for everey usage 
of this value. I'm not sure if this solution is better than to 
use stack slots for Lua objects references in the C++ stack and
registry entries for references to Lua objects from the C++

I thought it might be better to use stack slots for objects that 
live on the C++ stack instead of the registry, because these are 
normally not very long living objects and are in most cases 
destructed in reverse order of their construction. So the
C++ stack is in some way similar to the Lua stack.

> You can use a higher representation in C++ though, i.e. use C++ object
> to represent a lua userdata.

Yes C++ objects should be represented by lua userdata, if they are to
be used by Lua code.

My intention with using the "unused stack slots" was to make it easy
to write C++ code that uses some Lua objects without the need
to manage stack indices manually.

Best regards,