unsigned char* support via lightuserdata - #46
Conversation
There was a problem hiding this comment.
I'm not sure of this line.... I just copied it from above.
There was a problem hiding this comment.
This is a check of what Lua stack should look like in order to correctly convert the type from Lua -> C++. Since we are dealing with userdata, I think it should state 'userdata'.
There was a problem hiding this comment.
what is it passed to/from? just the lua side type()?
For other purposes it might need to be lightuserdata....
Note: I have tested this (using QImage::bits) and everything seemed to work.
There was a problem hiding this comment.
Actually, by looking at the code, it only seems to be used to distinguish overloaded methods, so it should be relatively harmless...
There was a problem hiding this comment.
So, what is it compared to?
I note that integer_type has integer; so it's probably not the lua type function....
There was a problem hiding this comment.
It is used to construct a "signature" of a method. It is generated in generator/classes.lua in function fill_wrapper_code, and subsequently used in print_metatable. The main idea was to use only a single overloaded function where there are multiple C++ versions that do not make sense in Lua. As an example - fun(char), fun(int) and fun(long) would all generate "integer" signatures, but the long version would get the least "defect" and therefore be chosen, the others will not be generated.
It is not actually used in any checking during runtime (there is another mechanism for that).
There was a problem hiding this comment.
ok then; should I make it userdata or lightuserdata?
|
bump |
2 participants
This closes Issue #44