Re: SLB vs LuaBind

[beo wulf <beowulf@...>]

I learned LuaBind not from reading it's documentation (human languages
are so impercise); but rather from reading it's examples.


One thing I think would be really helpful ... would be to present
Luabind examples in SLB. I.e. if we had things like:'

class Foo {
  public:
  int x;
  int foo(int y) { return y + 2; };
};

class Bar: public Foo {
  public:
  void bar() {};
};


int main() {
  using namespace luabind;

  lua_State *L;

  module( L ) [

      class_<Foo, boost::shared_ptr<Foo> >("Foo")
    .def_readwrite("x", &Foo::x)
    .def("foo", &Foo::foo)

    , class_<Bar, boost::shared_ptr<Foo> >("Bar")
    .def("bar", &Bar::bar)

    ]

    ;
}


Along side by side with the code implemented in SLB, it'd make the
transition much easier.

On Thu, Jan 6, 2011 at 2:34 PM, Jose Luis Hidalgo
<joseluis.hidalgo@gmail.com> wrote:
> 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 ----
>
>