Re: Light userdata

["Dylan Cuthbert" <dylan@...>]

You hit the nail on the head really - pointers are nasty so the light user
data system seems like a bit of a C old-school hack to me.

In C++ you can set up a double pointer "Weak Handle" system where the
pointer/reference people take is actually yet another pointer to the actual
data which, when destroyed, nulls out the double pointer everyone else is
pointing to.  You can do it in C too of course but it isn't transparent or
"wrapped".

If I was going the light userdata route I suppose I would have to set up
something similar here too, returning a nil when the parent object is
destroyed.

It seems a right PITA for something as integral as a vector_xyzw type
though.  I think I'm going to have to write a function for each vector I
want to give access to, that re-maps the lua vector type (which'll be a
metatable'd table right now) to the C vector_xyzw and another function to
convert the other way... could get a bit slow with code like this:

-- pos() and vec() convert from 128 bit vec C internal type to a table with
x, y, z pairs
object.set_pos( object.pos() + object.vec() )

-- now to play with pos a bit more
object.set_vec( object.vec() * 0.001 )

I could put the "pos" and "vec" tables into the object's fenv every frame,
and reconvert them out again at the end of every frame, but that's a huge
overhead and a very redundant way of doing things.

Regards

---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com


"David Jones" <drj@pobox.com> wrote in message
35384.1056622355@mango.vispa.com">news:35384.1056622355@mango.vispa.com...
> In message <bddmpo$jjf$1@main.gmane.org>, "Dylan Cuthbert" writes:
> > Question,
> >
> > Light userdata is simply a pointer to some internal C/C++ (native) data,
and
> > that data could be inside another structure, right?
> >
> > Light userdata has no metatable.
> >
> > Ok, so how do I destroy all uses (or nil them at least) of that light
> > userdata in lua when the C/C++ class/object its pointing to is
destroyed?
>
> Don't do that.
>
> If you have an object (or pool of objects, eg instances of some class)
> that must have an existence on both the lua and the C side then either
> lua or C must be responsible for managing the objects lifetime.
>
> If you can destroy the object from C then you can't let Lua have a
> pointer to it in the form of a userdata.
>
> There are a few approaches.  You can insert a proxy object which
> has a 1-to-1 correspondence to the real object, but reports "i am
> dead" whenever you try to do anything with it (from the lua side)
> after the real object has been destroyed.  You still have to manage the
> proxy objects though.
>
> My preferred approach in such situtations is to use integers on the
> Lua side and an array on the C side.
>
> Note you also have the same problem in C anyway.  When you destroy
> an object in C how to ensure that all pointers to it on the C side
> are NULLed out?  Answer: Much error prone, hard, and fragile work.
>
> The alternative is to let Lua manage the lifetime and destroy the object
> on the C side using a gcmethod.  You can't do this if the object is
> "precious"; for example a frame buffer, file descriptor, shared mutex,
> audio mixer channel.
>
> Cheers,
>  drj
>