[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Feature request: per-value uservalue
- From: Francisco Olarte <folarte@...>
- Date: Thu, 23 Mar 2017 17:32:21 +0100
On Thu, Mar 23, 2017 at 12:21 PM, Tim Hill <email@example.com> wrote:
>> one major difference between light- and full- userdata is the equality test.
>> light userdata is tested by value while full userdata is tested by reference.
>> this make big difference when you need to use them as table keys.
> hmmm, I’m thinking about that one. So a light userdata is really a void* pointer as a user value, so assignment just copies the “value” which is the void* pointer. Two values that have the same pointer, and will be equal. A full userdata is a garbage collected wrapper around a void* pointer, so assignment just copies the reference to this. Two values that refer to the same full userdata will be equal. Same semantics.
> So I’m not not sure how they are different? Do you mean that a light userdata and a full userdata to the SAME void* will be different? If so, then yes, but that’s *really* not a good thing to do anyway.
Thaye make difference when locating them. In the program I'm currently
working I have objects with are managed by reference counted pointers
on the C++ side, and which emit callbacks into lua.
For the ones using light userdata I increment the C++ refcount when
passing them to lua. The lua side then wraps them into an object wich
1.- Registers into a module table using LUD as key.
2.- Deregisters from said table when no more callbacks coming and
3.- decrements the reference count of the LUD on GC.
The C++ object callback then calls to a module callback passing this
as a LUD, the module callback locates the object using it and calls
the object lua callback.
For others I use full userdata. In this case I put a metatable on them
but I have to store them somewhere where the C++ object can find them,
( I tipically use the registry using this as a LUD as a key ), because
in C++ I can not just build a new FUD, as it will compare different (
even if I played tricks to make them compare equal I would need to
locate the original, potentially lua-customised object ). So I need
some kind of table keyed by some kind of value-type ( I always use the
registry for it, and have a rule of only using lightuserdata pointing
to the object-owned memory, normally this ).
Each one has its advantages and problems, but the full userdata
approach needs some kind of value-typed key to be able to be located.