 |
lua-l archive |
|
|
||
|
Hi! Am 23.09.2013 16:03 schröbte Matthias Beyer:
But another question, related to this stuff: What is the way how to do it? Should I work with light user data, when writing a lua binding for my application? I think, the light user data stuff is much faster, isn't it? And I want it to be as fast as possible... so, should I use light user data, or not? And if not, how to do it then?
AFAIC, there are three use cases for lightuserdata:1.) As a unique ID. Push a pointer to some global C symbol, and the linker will make sure that this userdata compares unequal to any other Lua value. See e.g. `debug.upvalueid()` (although the returned userdata are not valid (and unique) forever here).
2.) If you want to pass a pointer to something from one C function A to another C function B, where A runs outside of any pcall, and B runs inside a pcall. You can push a lightuserdata without the risk of a panic due to failed memory allocations. See argv-handling in `lua.c`.
3.) If you have data on the C side that will definitely live at least as long as the Lua state, you can use lightuserdata instead of normal userdata for "handles" on the Lua side. You probably should do some type checking (e.g. via a lookup table in the registry), and unless you are alone in your Lua universe, you cannot use metamethods ...
Everything else should be handled with normal userdata, IMHO. Philipp