Re: Providing C __eq method via metatable for userdata

[HyperHacker <hyperhacker@...>]

On Thu, Mar 10, 2011 at 19:13, Oliver <ogtifs@gmail.com> wrote:
> I found the answer in the source code for lua:
> function int luaV_equalval (lua_State *L, const TValue *t1, const TValue
> *t2) in lvm.c
> only tries to find the metatable __eq function if the data is FULL userdata.
> If it is lightuserdata, only the pvalues are compared.
> I felt the manual was rather unclear on this.
> 2011/3/10 Oliver <ogtifs@gmail.com>
>>
>> Hi all,
>> I am trying to make Lua a == b call a C function. I have provided a
>> metatable from C following the example described here:
>> http://lua-users.org/wiki/SimplerCppBinding
>> To debug I have tried to follow the logic steps described in the manual
>> http://www.lua.org/manual/5.1/manual.html#2.8
>> Yet the following script (invoked from lua_pcall after pushing instances
>> onto the stack and setting their metatables):
>> function testfunc(a, b)
>> print("Type:")
>> print(type(a))
>> print("Metatables equal?")
>> print(type(a) == type(b))
>> print(getmetatable(a) == getmetatable(b))
>> print(getmetatable(a)["__eq"] == getmetatable(b)["__eq"])
>> eqfunc = getmetatable(a)["__eq"]
>> print("Calling __eq directly")
>> print(eqfunc(a, b))
>> print("Calling via ==")
>> print(a == b)
>> end
>> produces
>> Type:
>> userdata
>> Metatables equal?
>> true
>> true
>> true
>> Calling __eq directly
>> *** INSIDE C FUNCTION ***
>> false
>> Calling via ==
>> false
>> i.e. the == operator does not call the C function
>> Could anyone please shed some light on this issue?
>> Thanks
>> Oliver
>

It does mention this in section 2.8:
> Tables and full userdata have individual metatables (although
> multiple tables and userdata can share their metatables).
> Values of all other types share one single metatable per type;
> that is, there is one single metatable for all numbers, one
> for all strings, etc.
Perhaps it could use a little more emphasis on the fact that light
userdata don't have individual metatables, and why (because they're
"small" objects that live on the stack, versus "large" objects that
live on the heap).

-- 
Sent from my toaster.