Re: SLB vs LuaBind

[Jose Luis Hidalgo <joseluis.hidalgo@...>]

Hi Tim,

On Thu, Jan 6, 2011 at 5:07 PM, Tim Mensch <tim-lua-l@bitgems.com> wrote:
> On 1/6/2011 2:36 AM, Jose Luis Hidalgo wrote:
>>    You're right with the syntax, sorry, that's what I meant. And about
>> SLB's missing features I would really appreciate an email telling me
>> so, that's the only way I can improve SLB for others apart from me.
>
> I didn't get past the lack of member variable bindings, and the lack of
> documentation, when I did my review.

The lack of documentation is entirely my fault, I find very difficult
to write it in English, if someone wants to
volunteer for reviewing, or write it, that will be an enormous
contribution to SLB and will also help lots of other people too
(hopefully).

The lack of member variable bindings is something that can be sorted
out, but it will be slower than registering functions, mainly because
apart from the function call per se there is a penalty for calling
__index and __newindex on each access, normal methods are cached
though if desired.

> I also need shared_ptr<> to be handled cleanly; I didn't investigate far
> enough to find out whether this was true of SLB. I also mentioned above
> the need to be able to add new values to an object, and have them
> persist across various shared_ptr<> instances of the object.

That works fine through policies and class handlers, I've been using
objects with inner reference counter (like, for example OpenSceneGraph
ref_ptr and Referenced classes) for a long time. More recently I also
added support for std::tr1::shared_ptr and similar, it needs a bit
more effort to be used, but it works fine:

http://code.google.com/p/slb/source/browse/tests/src/unit_007.hpp?r=c4466902fa641a54334d9e62cfdbfc984e5e9971
http://code.google.com/p/slb/source/browse/tests/src/unit_007.cpp?r=c4466902fa641a54334d9e62cfdbfc984e5e9971

> Otherwise, SLB looked like it probably had the features I needed, though
> I didn't do a benchmark to see how big it made things; I also want the
> binding to be pretty light.

Wrappers are based on some reusable base (virtual) class that makes
SLB slow compared to  hand written code, but the amount
of code needed to be written  will be similar to the code generated by
the templates.

The main idea behind SLB is making our C/C++ code accessible to a
script, so I've put all the effort in making wrappers written by the
user  as elegant, flexible and easy as possible. That goes directly
against efficiency in most of the cases, if you find yourself stuck
with some calls that makes your program run slow, you can always wrap
a method, or a class, directly using  lua_c_functions (SLB, of course,
supports registering as members lua_c_functions).

But, even so, If you think SLB can be improved for speed, something I
didn't even started to think about, It would be great to hear where or
even better how make it possible, I'm open to benchmarks, ideas, or
whatever :)

Best Regards,
   JL.

-- 
  Jose L. Hidalgo Valiño (PpluX)
  ---- http://www.pplux.com ----