Lua C + + binding lunar, Luna

Server-side engine script, our project is developed on the old-end tour project, and the Lua script is taken. The current development trend of the server is thin engine, Fat script mode, basically the engine is responsible for very few functions, mainly network, fixed frame, timer, the engine by exporting the appropriate interface to the script layer call, the data is basically placed in the script layer, the engine layer only records some of the relevant functions necessary data, As in our engine layer, we record the verification information related to the disconnection, where the player's battle information is used to forward the communication data between the battle and the client. The advantage of thin engine fat script is that after the infrastructure is set up, it can play quickly, and because of the existence of the script virtual machine, the stability and robustness of the service-side code is guaranteed, the disadvantage may be the long-standing script execution efficiency problem.

Our engine portal is in C + +, and the C + + level is the engine layer, and the LUA layer is the scripting layer. Back to the topic, the engine layer and the scripting layer need to be able to switch freely, can easily be called from the engine layer into the scripting layer, the script layer also needs to easily use the engine layer to provide data objects and interfaces, our server is a very lightweight binding scheme, is lunar.h (HTTP/ Lua-users.org/wiki/cppbindingwithlunar), as you can see, this is an older scenario that supports Lua5.0, version 5.1, 5.2, 5.3 may need to modify some interface calls to compile through.

For Lunar.h, it provides the following features:

1. Provides a definition mechanism to declare C + + objects at the LUA layer

2. A push interface is provided that can pass in C + + objects in the C + + layer (the only UserData is to call push on the same object multiple times, passing in the same UserData object), which can be called at the LUA layer to register the interface called to the LUA layer

3. The call interface is provided, which can invoke an extension function defined by the LUA layer in the C + + layer, or the LUA function interface (HTTP://LUA-USERS.ORG/WIKI/CALLINGLUAFROMCPP) that invokes the object, which refers to the C The + + layer invokes the interface that the object registers to the LUA layer, thus achieving the purpose of not having to implement the function repeatedly, but in theory the efficiency will decrease, the object sugar has a taste interface, a C_taste interface (registered for use with the LUA layer), the two functions are duplicated, Call allows you to implement only the C_taste interface, and when the C + + layer needs to call this interface, it calls the C_taste interface without having to write a taste interface repeatedly.

4. For the life cycle of an object, the default processing for lunar is that the object is destroyed by the C + + layer, but for objects created at the C + + layer, the behavior of the destruction can be handled by the LUA layer by setting the GC parameter to true at push. and for C + + objects created in the LUA layer, must be destroyed by the C + + layer, this part of the special attention, we do this kind of object is either a global object, the declaration period from the creation to the server shutdown, such as DB object, or a function call to use, will not be cached to use elsewhere, After the function call enters the engine layer interface, the engine layer recycles the object, such as the buffer object, which is then delete after the bottom of the network buffer is sent, and the script layer does not cache the buffer object and then uses it again at some point ( Can not determine whether the underlying has been recycled this object), is a latent rule.

For lunar, its code comments write well, the interface is not much easier to understand, its implementation code translated into LUA code as follows (to implement a sugar C + + class as an example)

1Methods = {2New =new_t,3Func1 = thunk,--With upvalue func1 regtype4Func2 = thunk,--With upvalue Func2 regtype5     -- ...6 }7USERDATA_MT = {8__metatable =methods,9__index =methods,Ten__tostring =tostring_t, One__gc =gc_t, AUserData = {__mode ="v", Lightuserdata =fulluserdata, ...} -["Do not trash"] = {__mode ="k", Fulluserdata =true, ... } -}--exists in the registration form theMt = {__call =new_t} - setmetatable(Methods, MT) - _g["Sugar"] = methods

Luna.h is also a way of the Lua C + + binding, the latest Luna version is lunafive (http://lua-users.org/wiki/LunaFive), Lunafive personally think has not reached the lunar level of use, It has some advantages that lunar does not have, including

1. Direct Support Lua5.3

2. Support namespace, second parameter of register interface, default to Global table

3. Provides an interface function to get the property, and lunar needs to write the Set/get function directly

4. Support to save the C function as an object, such as local func = Obj.func, then func () is legal, and lunar cannot

The disadvantages relative to lunar are:

1. GC behavior is the default delete, which means that the object life cycle is controlled by the LUA GC and the payback time is uncertain

2. The multiple push of the same object is not considered, resulting in more than one userdata, lunar will only produce a

The code implementation of Lunafive is translated into Lua code as follows, using the __index is function when the original table/userdata to get C + + object pointers, through index to correspond to the record member variables and member functions, A maximum of 128 variables and 128 functions are supported.

1USERDATA_MT = {2__gc =Gc_obj,3__tostring =to_string,4__eq =equals,5__index =Property_getter,6__newindex =Property_setter,7["prop_name1"] =1,8["prop_name2"] =2,9     ...Ten["func_name1"] =1| (1<<8 ), One["func_name2"] =2| (1<<8 ), A     ... -}--exists in the registration form - _g["Sugar"] = Constructor

Our project uses lunar, although old, but at least withstood the test of the end-trip project and the hand-tour project, although there is no very fancy function, need to abide by some unspoken rules, but if not the pursuit of the ultimate, lunar this solution should be enough.

Now I'm looking at a new solution, an open source project on GitHub lua-intf (https://github.com/SteveKChiu/lua-intf), taking advantage of some of the c++11 's new features that look pretty classy, It seems that the information is not much, and after careful study, there is a chance to share again.

Lua C + + binding lunar, Luna