Re: ANN: LuaState (A C++ Lua Wrapper and enhanced Lua 4.1 Distribution)

[Edgar Toernig <froese@...>]

Luiz Henrique de Figueiredo wrote:
> 
> >> never made it public, and it sits unused in my project now.  It was working
> >> fine, but in the end a system like that suffers the same issue as with using
> >> floating point values to pass around C pointers in Lua-- it isn't exactly
> >> safe.  For example on my project the Lua number type is 32-bit float, and
> >> using that type to work with 32-bit pointers and integers is dubious.
> >
> >i had thoughts along the same lines... is there any way around this (not
> >using userdata which - as i understand - actually is a void*)?
> 
> Userdata is the way to send C pointers to Lua (and back). It was designed from
> the start for this use. Why try to avoid it?

Because it is too costly.  Often you don't need the garbage collection
facilities or type attributes.  I.e. when you try to map C-pointers or
numbers to Lua objects.  Often this is done by casting these C types to
a number but this will not work at all if your number type is too small.
The only way to do this is to convert the C value to a string representa-
tion - not very elegant.  In Lua 4.0 this problem was not that big because
Lua itself performed the mapping from pointer to userdata object.  With
the (IMHO better) 4.1 userdata handling this is no longer the case and
something better than the indirection via strings should be present.

A LUA_TUPOINTER and LUA_TUNUMBER would help very much; in fact it will
be present in future Sol versions.  With a note of course: objects of
these types should not be exposed to the Lua/Sol application!  The app-
lication would be able to crash the whole system if you do![1]  But it's
very handy on the C API side.  You may store these types in unexposed
(upvalue/registry) tables to create C->Lua mappings.  And the additional
code to implement them is negligible.

Ciao, ET.

[1] But this is also the case when you convert to strings, cast to numbers,
or do not use the tags properly.


PS: The idea to access the global and registry tables via pseudo indices
too is marvelous ;-)