Re: request for interest/participants: another lua C++ binding

[Tyranni <tyranni@...>]

Oliver,

>    * luabind: most powerful, but requires boost, and syntax a little
>      unnatural (IMO)

What is your specific issue with using boost?

Also, I use luabind not just as a binding system, but also to abstract dealing with the Lua stack.
The luabind::object class and luabind::object_cast functions are extremely useful for this:

double d = luabind::object_cast<double>( luabind::globals(L)['my']['nested']['table']['entry'] );
// yes that looks sorta ugly but in practice you don't write it like that


>    * swig and tolua++: don't allow for variable argument lists (AFAICT)
>      or for logging callbacks and gets/sets

SWIG supports C varargs.  I don't think it supports Lua varargs since the Lua-SWIG module is
targeted to Lua 5.0.  You can add it and send them patches.

In terms of adding logging functionality, there is complete flexibility in SWIG through the use of
typemaps.  They are a bit of a pain to use (you normally don't have to), but you can.

One problem with SWIG is that it is one-way... you can only access C++ objects and functions from
Lua.  You cannot (easily) get those objects back in C++.  [Something like this could be possible
with some adapating tools that combine SWIG and luabind.]


I'm not trying to squash your call to arms; I'm just trying to give you more info.

-Evan


Oliver Schoenborn wrote:
> Hello, I'm somewhat unhappy with the existing bindings to C++. The major
> ones
> 
>    * lua++: clean and simple, but requires custom lua
>    * cpplua: some good ideas, but some less good, and doesn't seem to
>      be maintained
>    * luabind: most powerful, but requires boost, and syntax a little
>      unnatural (IMO)
>    * swig and tolua++: don't allow for variable argument lists (AFAICT)
>      or for logging callbacks and gets/sets
> 
> I have had to use basic lua binding to C for on-the-job projects, and
> I'm thinking that because of the above, perhaps yet another C++
> alternative that has the following characteristics might fill a need:
> 
>    * no dependency on boost
>    * usable with any lua (esp core dist)
>    * combines the best of cpplua, lua++ and luabind, without
>      necessarily going as far as luabind, remains usable if some parts
>      are dealt with swig
>    * basically hides all notion of stack (user wouldn't have to know
>      there is one)
>    * support logging of callbacks and sets/gets
> 
> 
> Any comments on the above would be greatly appreciated (e.g., maybe such
> a binding already exists?).
> 
> The idea is to host it on SourceForge (e.g.), it would be great to have
> lua users involved (with more experience that I do, e.g. on stack use
> and patterns of communication between C++ and lua interpreter).
> 
> Examples of use:
> 
> void func(const LuaArgs& args) {
>    if (args.size() < 1)
>    {
>        LuaLog(err, "error message");
>        return; // automatically causes return 0 to Lua
>    }
>    if (args[2]) // do something with args[2]
>       ...
>    luaLog(trace, "func() called");
> 
>    LuaObject a("a"); // will be "nil" if doesn't exist
>    int aa = a; // auto convert to int, or throw if can't
>    int bb = (a.nil() ? 0 : a); // won't throw, don't care if error
>    std::string sa = a; // converts to string? or throws?
> 
>    // automatically pushes appropriate lua types onto stack
>    // and handles return value count
>    luaReturn("aString", aFloat);
> }
> 
> int main()
> {
>    LuaInterpreter lua;
>    lua.newLog(trace, stuff); // use lua code to implement this?
>    lua.newTable("ns");
>    lua.register("ns.func", func); // will be wrapped so LuaReturn works
>    LuaObject a = lua.newValue("a", 1); // let C++ compiler determine type
> 
>    lua.doString("ns.func(2)");
>    lua.doFile("file.lua"); // may call ns.func()
> }
> 
> The log functionality needs a fair bit of thinking but want it to be
> simple to use.
> 
> Any feedback or ideas about things missing from the three libraries
> (lua++, luabind, cpplua) would be appreciated.
> 
> Thanks,
> Oliver
> 
> 
>