[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.2.0 (alpha-rc2) now available
- From: Nick Gammon <nick@...>
- Date: Sat, 20 Nov 2010 12:59:21 +1100
OK, I'm confused now. I admit it.
I am attempting to convert my (C++) program, at least on an interim basis, to work with Lua 5.2.
In the old code, I stored a pointer to the underlying C++ structure using the LUA_ENVIRONINDEX pseudo-index, as recommended in the Lua 5.1 Reference Manual (page 29). That could then be retrieved by a script function to get back at the C++ data. (Re-reading seems to indicate I may have misinterpreted the intention of that index - however could it be interpreted as being a table for data accessible to C only, and thus safely used for such purposes?).
Now according to the 5.2 manual:
> Pseudoindex LUA_ENVIRONINDEX and functions lua_getfenv/lua_setfenv were removed. C functions do not have environments any more.
It goes on to say:
> Use an upvalue with a shared table if you need to keep shared state among several C functions.
However as far as I can see LUA_REGISTRYINDEX still exists. And I note that it is used in Lpeg, lsqlite3 as well as my own code.
So what is really the recommended way of storing some global data (eg. a pointer) for Lua to get back its C environment? An "upvalue with a shared table" is different from the registry is it not?
Is there some reason you suggest using the upvalue rather than the LUA_REGISTRYINDEX table? Would it be faster?
Also, the defines in lauxlib.h for the "reference system" seem to have gone out the window, eg.
#define lua_unref(L,ref) luaL_unref(L, LUA_REGISTRYINDEX, (ref))
#define lua_getref(L,ref) lua_rawgeti(L, LUA_REGISTRYINDEX, (ref))
(and others).
These are used by luacom. They have been removed however without comment in the compatibility section of the reference manual. What is the recommended behaviour here? To put them back (so luacom compiles)? Or for luacom to be rewritten to work without them?
- Nick Gammon