Re: linking tables to C++ objects?

[Graham Wakefield <lists@...>]

On Feb 27, 2007, at 11:11 AM, Sam Roberts wrote:

> > Somehow I need to get the userdata back onto the lua stack, based
> > upon the identity of the C++ instance pointer.  getfenv() will not
> > help, since it requires that the call was made as the result of a
> > lua_CFunction call from Lua, not a lua_pcall from C.
>
> I really don't know what you mean here.

This refers to the option of storing the lua table inside the  
userdata's environment; but this only helps if you already have the  
lua userdata on the stack.

> > This will not work because it is only valid in the context of a
> > lua_CFunction call, and my call comes from a later C++ triggered
> > lua_pcall().
>
> I don't know what you mean by that, either, sorry, it sounds like you
> are doing pretty much exactly what I am doing with swirl inside
> callbacks from vortex, a C BEEP implementation. The Vortex kernel  
> calls
> a C function, and I use a lua_State to map addresses back to their  
> udata
> objects.

Yes indeed, very similar.

> See v_obj_get():
>
> http://luaforge.net/plugins/scmcvs/cvsweb.php/swirl/vmain.c? 
> rev=1.3;cvsroot=swirl
>
> After doing v_obj_get() I could call lua_getfenv() to get the table  
> from
> the udata object.

I see. In the globals table you have something like this

LUA_GLOBALSINDEX.V_MAIN._objects[ptr] = (some lua object, e.g. table).

In my case I'm using the registry, rather than a table inside the  
globals table, but its pretty much the same otherwise.  The reference  
stored here prevents garbage collection.

I also notice you use luaL_ref to retain the location of lua  
functions for later callbacks from C; I hadn't used luaL_ref before,  
but I wonder whether this might be a better solution to my problem.


> Sam