So lightuserdata would just be a 64bit value (and in Lua32 then a 32bit value).
And you anyway can use metafunctions with lightuserdata? ... this is a
bit a surprise to me ... but sounds interesting of course... .
Can you show the code, how you connect the metatable to your
lightuserdata element?
If you don’t use 3rd library, you can also use 48bit object Id + 16bit type id (or 56+8) for your objects without change lua implementation.
On Tue, Feb 22, 2022 at 2:51 PM 云风 Cloud Wu <cloudwu@gmail.com> wrote:
>
>
>
> Soni "They/Them" L. <fakedme@gmail.com>于2022年2月22日 周二21:39写道：
>>
>>
>>
>> On 2022-02-22 10:24, 云风 Cloud Wu wrote:
>> >
>> >
>> > Flyer31 Test <flyer31@googlemail.com>于2022年2月22日 周二20:50写道：
>> >
>> > Why don't you just use "normal c userdata", if you want metafunctions?
>> > (I assume that in this case your userdata quite sure is anyway somehow
>> > "more important" / more "heavy"?).
>> >
>> >
>> > userdata is a GC object , and we don’t need lua manage the lifespan of
>> > objects.
>> >
>> > For example, we have a game scene graph in C side, only a few objects
>> > (when needed) export into lua side. So,not all C object has the lua proxy.
>> >
>> > Userdata is only a reference to scene node. We need another (weak)
>> > table to cache them. (Scene node pointer-> userdata)
>> >
>> > Another usecase is fixed-point number or complex number library. A
>> > value type is much cheaper than GC object.
>> >
>> >
>> >
>>
>> You probably want a full userdata to avoid UB. LU aren't collected, so
>> you can't know if it's still alive or not/when to free it/etc.
>>
>> "Optimizations" like these are a security nightmare.
>
>
>
> Many object can fit into 64bits , short strings for keys . Fixed point numbers, 4 half float vector , etc.
>
> For big objects, we can also use 64bit ID to refer them, and we can easily know if the object alive.
>
> Lightuserdata is much cheaper when we need to push a C object reference into lua side.
>
>>
> --
> http://blog.codingnow.com
