Lua and C are inherently good friends. Language developers provide a series of APIS for them to communicate through stacks. It takes some time to develop the game logic using Lua. The following mainly summarizes the application of Lua c api. 1. Expansion Lua has a very small core and mainly includes an interpreter. Other functions can be extended as plug-ins through dynamic libraries, i/O, string, math, table, and other built-in libraries are implemented in this way, but they are integrated into a lua. dll. To create a module in the form of a dynamic library, you need to specify the luing between the lua function and the c function through the luaL_Reg array in the code, and then implement the c function. Finally, in luaopen_xxx (xxx is the module name) register this luaL_Reg. Here is a very simple example. It uses VC ++ to create a Console DLL: www.2cto.com # include "lua. h "# include" lualib. h "# include" lauxlib. h "# include <math. h> int mysin (lua_State * L); static const struct luaL_Reg mymathlib [] = {"sin", mysin}, {NULL, NULL }}; static int mysin (lua_State * L) {www.2cto.com double d = luaL_checknumber (L, 1); lua_pushnumber (L, sin (d); return 1;} _ declspec (dllexport) int luaopen_mymathlib (Lua_State * L) {luaL_register (L, "mymathlib", mymathlib); return 1;} compile it into a dll and put it in the lua interpreter directory. Lua test code: require "mymathlib" local a = mymathlib. sin (0.5) print (a) II. the most widely used field of Lua as a script system is game development. WOW's UI and plug-ins make it famous. In such an application, Lua acts as a sub-system of the Application for configuration or business processing. When integrating Lua with an application, you must use the Lua c api. According to its specifications, you need to write a series of static functions as the bonding code between Lua and the application. If you want to use a C ++ object in Lua, you can use it as userdata, create a retriable for it, and put the bonding function into it. The key is to point _ index to the retriable itself, in this way, when Lua accesses the field of userdata, __index will guide it to search for the retriable itself to obtain the registered bonding function. There are many open-source bonding code generators. They all do some work in precompile, so they do not use macro or template. The two methods represent toLua ++ and luaBind. I prefer toLua ++. On the one hand, this method is straightforward, and on the other hand, I prefer template. In WGAME, we also replaced the previously poorly written bind code with toLua ++. Currently, Lua is heavily used in UI and level logic, and tens of thousands of lines of bind code will be generated, because the project uses an event-driven approach, we can see that the overall performance of the game is very small in profile. LuaBind has probably known about it and has never been used in actual projects. I will not comment on it here. When using toLua ++, I'm most curious about how it supports the key features of C ++. In addition to the member functions mentioned above, for the support of polymorphism, it adds a number after the static function and determines whether the parameter corresponds during the call to traverse and find the correct static function; for complex member variables, it will automatically generate the get/set method. The inheritance relationship is implemented by using the Child class as the retriable class. In the spirit of a new wheel, I tried to write a simplified Automatic Generator [I am on github]. I have defined several keywords as export identifiers for classes and Methods: {module_begin = "beg", module_end =" LUACBIND_MODULE_END ", method_begin =" LUACBIND_METHOD_BEGIN ", method_end =" LUACBIND_METHOD_END "} util. h defines the macros required to generate bind code, parser. lua specifies. the hfile is scanned to generate bind code. After register in the main function, it can be used in lua. 3. The c api and Debug libraries of the debugger Lua provide the necessary methods to implement the debugger. They correspond to two implementation methods: one is implemented by Remdebug and implemented directly by lua; the other is to use c api. No matter which method, the use of HOOK is required, but the use of Lua debug library is more convenient than the c api, because the stack balance issue does not need to be considered. When using the c api to implement the debugger, you can use lua_newthread to create a coroutine. Then yield/resume/getstack/getlocal will apply to it. breakpoint is usually implemented in the yield method in the hook, however, stack tracing cannot be performed after the hook is returned, because after traceexec calls the corresponding hook function based on the hook mask, if the state is LUA_YIELD, it will call luaD_throw, longjmp cannot be used for backtracking. Using the two-day free time on duty during the Spring Festival, a command line debugger [I am on github] is implemented based on lua 5.2. Currently, there are only a few simple functions: load/run the lua script, set/clear breakpoints, and view simple type variable values in a single step. For the command format, see README.