Use fragmented time, first of all the knowledge points to be prepared in advance. Recently busy, preparing an article to bind C + + objects into Lua. But, do not want to easily start, hope to do enough preparation.
This translation comes from lua-users.org, the original address.
Light User Data
Light UserData, like heavy UserData, was a form of UserData, which is one of the basic data types in Lua. Light UserData is characterized by the following properties:
1, light userdata and heavy userdata has deceptively similar names, and both has the property type (x) = = ' UserData ', but These of userdata is otherwise quite different in behavior
2, a light userdatum represents a single pointer to A physical memory address (void *), which is typically a 32-or 64-bit Value depending on platform.
Light UserData is intended to store C pointers in Lua (Note:lua numbers could or May is suitable for this purpose Depe Nding on the data types on the platform).
3, a heavy userdatum represents a region of the mutable bytes allocated in Lua's memory and managed by LUA (garbage collected).
This is the only memory in Lua, and is permitted to read/write directly from C (via the UserData ' s pointer) without t The He C API.
4. Light UserData has the semantics of values, while heavy userdata has the semantics of objects.
Objects has a unique identity. Heavy UserData constructed with the same data would always be distinguishable (e.g. Rawequal would differentiate them by memory address);
UserData so constructed would never be distinguishable because they is compared by value not by address.
5, light UserData (unlike heavy userdata) is not garbage collected.
Lua implementations typically fit each light userdatum in a single register and copy them around by value, while heavy use Rdata is allocated in the heap and passed around by reference (pointer).
6, Equality:if X is a lightuserdatum, then x = = y If-and-only-if y is a light userdatum representing the same pointer.
Light UserData can is used as table keys, in which case x = = y implies t[x] and T[y] refer to the same table value (though Not necessarily, that t[x] = = T[y] Since nan ~= nan).
The __eq Metamethod has a no effect on light userdata (note:the manual isn ' t clear on this.
7, Light UserData (unlike heavy userdata) has no per-value metatables. All light UserData share the same metatable and which by default are not set (nil).
8, ToString (x) typically displays the pointer in hex notation, although this is specific to LUA implementations.
Some Interesting points:
1, A common technique for mapping C pointers to Lua values are to store A light UserData of this pointer as a key in the Reg Istry table.
These mapping is not automatically garbage collected, and you might want to use a weak table rather th The The registry (which by default was not weak, but a weak table can being stored in it).
2, Some people represent handles rather just pointers as lightuserdata. It's possible to represent other data in them as well.
3. Pointer and Non-pointer UserData in a-might conflict (e.g. storing both in the registry Ta BLE).
4, light UserData is created from the C API via [Lua_pushlightuserdata]. Out-of-the-box, Lua doesn ' t provide a-to-create Lightuserdata from Lua.
Light UserData and full userdata some similar, is a kind of userdata. Light UserData is a basic data type in Lua. Light UserData has the following characteristics:
1, light UserData and full userdata have the same name. Both types (x) are "UserData", but the behavior of the two UserData is completely different.
2. Light UserData represents a pointer to physical memory. (void*) Type pointer. The pointer length is 32bit or 64bit depending on the platform. The main purpose of light UserData is to store C language pointers in LUA code.
(Note: Lua number is not suitable for storing C point on different platforms.)
3. Full UserData represents a variable-length memory address that is assigned by LUA to be managed by LUA GC. This is the only way to allow the allocation of memory in LUA code through the C language.
4, light UserData is a value type, full UserData is the object type, each object is unique. Two full userdata with the same data are different. Rawequal will differentiate the full userdata from the memory address.
Light UserData are compared by value rather than by address.
5, light UserData can not be GC garbage collection. However, full userdata can be collected by GC garbage collectors. Lua implements light UserData to pass a value through a copy, however, full userdata is an allocation over the heap, passing the full userdata through pointers (references).
6, Equality: If X is light UserData, if X==y is true, only X and Y are a light userdata and point to the same pointer.
Light UserData can be used as the table key, T[x]==t[y] means pointing to the same value.
7, light UserData is all light userdata share a metatable, usually the default is nil, and full userdata is each value has a separate metatable.
8. The ToString () method shows the address that light userdata points to by 16 binary.
Common points of view:
1. Normally mapping C points to Lua Code value is the key that points to the pointer's light UserData in the registry.
It is important to note that this mapping is not automatically reclaimed by GC and can be used instead of the registry by using the weak table weak reference table.
2, some people just think light userdata can only represent pointers. However, you can also use light userdata to represent other types of values.
3, do not mix light userdata and full userdata, can easily cause confusion.
4. Create light UserData through Lua_pushlightuserdata in the C API, but no form of light userdata is provided in LUA code.
Lua vs. C + + Interaction series: Light UserData translation
