Luatinker Bugs and defects

Luatinker bugs and defects

Luatinker is a good set of C + + code and LUA code binding library, the author is Korean Kwon-il Lee, the author should be referring to the luabind, in order to simplify and avoid too heavy to achieve. Its official website is in Http://gpgstudy.com/gpgiki/LuaTinker, but unfortunately all is Korean, and the newest code can download in Git, https://github.com/zupet/LuaTinker. Compared to luabind,luaplus such libraries, the implementation is very very very very very light, about only more than 1000 lines, at least give you a chance to understand and rewrite some functions, so it has a lot of mass base in the country. And its slim figure also makes it possible to dissect how a scripting glue layer works.

But on the other hand the number of Luatinker bugs is not a minority. There are many students have been scattered to put forward. Here is just a summary, but also thank Fergzhang classmates. He helped to point out a lot of questions.

1. Bug (Error)

The first problem is that the comparison of the int64_t data is wrong, without regard to the sign bit situation at all.

Static int lt_s64 (lua_state *L) {    // without considering the sign bit at all, actually using memcmp    12  sizeof(longlong0);     return 1

The second problem, when dealing with the modification function (__newindex) of a class member, is not considered to handle the parent class member, while Luatinker supports inheritance, and the int lua_tinker::meta_get (lua_state *l) (corresponds to __ Index) is also supported. This should be an omission of the author.

intLua_tinker::meta_set (Lua_state *m)    {Enum_stack (L); Lua_getmetatable (L,1); Lua_pushvalue (L,2); Lua_rawget (L,-2);    Enum_stack (L); if(Lua_isuserdata (L,-1) ) {User2type<var_base *>::invoke (L,-1),Set(L);} Else if(Lua_isnil (L,-1)){    //there is no call to Invoke_parent (L) to handle the parent class.Lua_pushvalue (L,2); Lua_pushvalue (L,3); Lua_rawset (L,-4); } lua_settop (L,3); return 0;}

The third bug, using I64D, an outdated label, I64D should be a formatted string label that is old and old for Microsoft, and completely portable. Should be changed to%LLD.

Static int tostring_s64 (lua_state *L) {    char temp[];     " %i64d ", * (longlong1));    Lua_pushstring (L, temp);     return 1 ;}

The destructor for the 4th Bug,var_base base class does not write virtual

struct var_base{    // The original destructor did not write virtual    virtual ~var_base () {};     Virtual void Get 0 ;     Virtual void Set 0 ;};

One of the 3 constructors in the 5th bug,table does not increase the reference count, which many students have pointed out on the Internet.

Lua_tinker::table::table (lua_state* L,Const Char*name)    {lua_pushstring (L, name);    Lua_gettable (L, Lua_globalsindex); if(Lua_istable (L,-1) ==0) {Lua_pop (L,1);        Lua_newtable (L);        Lua_pushstring (L, name); Lua_pushvalue (L,-2);    Lua_settable (L, Lua_globalsindex); } m_obj=Newtable_obj (L, Lua_gettop (l)); //The original code does not have this paragraph, the lack of increased reference count processingM_obj->inc_ref ();}

, CSDN's ainn_pp also wrote this question, for reference: http://blog.csdn.net/ainn_pp/article/details/2773855

1. Defects

Luatinker also has many flaws and deficiencies,

The first shortcoming, the various function parameter support number is uneven. Luatinker writing time should be relatively early, without the support of C + + 11 template variable (Variadic template), so can only write multiple templates function (class) to solve the problem of multi-platen parameters. But luatinker on the one hand write the number of parameters is very small, on the other hand luatinker the number of local support parameters are completely non-uniform, 3, 4, 5 have. In fact, this part is best used in C + + 11 (Variadic Template) rewrite.

The second flaw was a mishap, and Luatinker's support for the LUA process took a laborious, but not flattering, approach. You must define the first parameter of the process as Lua_state *l, and the return value must be Lua_yield (L, 0). Such restrictions greatly limit the use of.

//The first parameter must be (lua_state *lintTESTFUNC2 (Lua_state *l,floata) {printf ("# TESTFUNC2 (l,%f) is invoke.\n", a);//the place to return must be called Lua_yield    returnLua_yield (L,0);}classtestclass{ Public:    //class functions are the same    intTESTFUNC2 (Lua_state *l,floata) {printf ("# TESTCLASS::TESTFUNC2 (l,%f) is invoke.\n", a); returnLua_yield (L,0); }};

If you actually distinguish it in the encapsulation of its function, you can avoid this trouble by calling Lua_yield at the end. I don't have much appetite for this implementation.

The third place is, is the reference variable (parameter), the issue of registration, in fact, this is not luatinker problem, but the C + + template problem, C + + automatic template function parameter deduction is the existence of some unspoken rules. One of them is the lvalue transformation, which is clearly explained in the article "CUJ: Efficient Use of standard libraries: explicit function template parameter declarations and STL". The following example:

// The following notation cannot be referenced, and parameters must be explicitly specified.  //Lua_tinker::set (L, "ref_a", ref_a); // explicitly declaring reference parameters Lua_tinker::set"ref_a", ref_a);

The 4th problem is that the removal of CV (const volatile) is not ideal for template processing. Within LUA, the registration of an external class is using the function Class_add, which is a meta table associated with a LUA with a name, which, in the later use of the class, obtains the class name through the Class_name<t>::name function, but in practice, Many times T is a modifier with a const or a volatile character. Included, Luatinker removed the const in some of the processing, but in many places ignored the problem, the compiler does not think that ClassA and Const Class A is a thing. So the result is that sometimes you can't get your userdata to find the meta table.

Lua_tinker::class_add<testa> (L,"TestA"); Lua_tinker::class_con<TestA> (L, lua_tinker::constructor<testa>);//with the help of a template function to implement a method, you can find the corresponding class name (registered to LUA name) through class .Template<typename t>structclass_name{//Global Name    Static Const Char*name (Const Char*name =NULL) {        Static Chartemp[ the] =""; if(name) {strcpy_s (temp, name); }        returntemp; }};

Fergzhang classmate, for the luatinker of some bug fix made a version. It seemed to support the 5.2 version, and he put it in the https://github.com/zfengzhen/lua_tinker_5.2.git.

And my own for the above problem realized a set of Luatie library, no time, have time to sort out. The internal features of C + + 11 have made some rewriting.

Https://github.com/sailzeng/zcelib/blob/master/src/commlib/zcelib/zce_script_lua_tie.cpp

Https://github.com/sailzeng/zcelib/blob/master/src/commlib/zcelib/zce_script_lua_tie.h

There are examples of tests inside the project, but they are not sorted out and look more troublesome. After finishing up and then write an article on the introduction.

Finally, while I was finding fault, I would again express my gratitude to Luatinker author Kwon-il Lee, This set of code helps me understand how to bind scripts and understand some of the basics of MPL. And frankly, Luabind is tied to boost, and it's hard to simplify the luatinker from the code (reading the boost code is just not pleasant), it's really a great thing that Luatinker's author might More aware of the benefits of light for the code, Kwon-il Lee has a section on the home page explaining why it doesn't support the overloads supported by Luabind, and I think a good library is always simple.

Luatinker bugs and defects