 |
lua-l archive |
|
|
||
|
|
>I've decided that intrusive structures (in C++) are the way to go (they can kill themselves on delete).
>One thing to note is that you can have it treat uint32_t as a lua_Number. Then you won't have as MANY collisions... If you add this to your tolua spec: typedef signed char int8_t; typedef unsigned char uint8_t; typedef short int int16_t; typedef unsigned short int uint16_t; typedef int int32_t; typedef unsigned int uint32_t; >...then it will understand that all of those are really numbers. The code should be faster too. >Tim Hi Tim,
In the example I posted this solution should work just fine.
Another way we use uint32_t is to represent hashed strings, rounding errors with luaNumber would (and has) cause big problems in that case.
My plan of attack was fool hearty, I can't just change the keys to use Udata addresses because I don't know what the Udata address is before I need to do a table lookup in tolua_ubox. Looking at the code for tolua_pushusertype, if the value is already a key in the ubox table it re-uses the Udata block and just ties a new metatable to it, but that can't be safe! It probably makes sense to pull the Udata out of the table and make a new one for the new value. The function is unfortunately not named tolua_createandpushnewusertype.
No, it's too much work and I don't understand it well enough to start monkeying around with the guts! I'm going to just pull the local variables out of the function and make them local to the script, at least this way the uint32_t memory address will never get re-used while the script lives. I'll probably have to make them global so they're safe in all scripts, or force a full garbage collect at the end of each script. Maybe at some point we can dedicate some time to stripping out toLua as you suggested. Is it Christmas vacation yet?
Thanks again Tim,
Jay |