lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 {
  int x;
  int foo(int y) { return y + 2; };

class Bar: public Foo {
  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
<> wrote:
> Hi Tim,
> On Thu, Jan 6, 2011 at 5:07 PM, Tim Mensch <> 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:
>> 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)
>   ---- ----