[C++-sig] Re: Interest in luabind

[dalwan01]

>
> Moving this to the C++-sig as it's a more appropriate
> forum...
>
> "dalwan01" <dalwan01 at student.umu.se> writes:
>
> >> Daniel Wallin <dalwan01 at student.umu.se> writes:
> >>
> >> > At 18:03 2003-06-17, you wrote:
> >>
> >>http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/16
> 73338 is
> >> >>more recent and also relevant to your question.
> >> >>
> >> >>In short, I'd love to see luabind in Boost, and I'd
> hate to see
> >> >>it happen without substantial code sharing with
> Boost.Python.
> >> >
> >> > I agree. It seems like a lot of code could be shared.
>  For
> >> > instance, the conversion system between
> base<->derived should
> >> > work exactly the same and we could probably plug in
> BPL's system
> >> > for this without much trouble.
> >> >
> >> > It would also be really nice if we could share most
> of the
> >> > front-end code (declaration of scopes, classes and
> functions).
> >> >
> >> > Note however that there are quite a few differences
> in design,
> >> > for instance for our scope's we have been
> experimenting with
> >> > expressions ala phoenix:
> >> >
> >> > namespace_("foo")
> >> > [
> >> >    def(..),
> >> >    def(..)
> >> > ];
> >>
> >> I considered this syntax but I am not convinced it is
> an advantage.
> >> It seems to have quite a few downsides and no upsides.
> Am I
> >> missing something?
> >
> > For us it has several upsides:
> >
> >   * We can easily nest namespaces
>
> IMO, it optimizes for the wrong case, since namespaces are
> typically flat
> rather than deeply nested (see the Zen of Python), nor are
> they
> represented explicitly in Python code, but inferred from
> file
> boundaries.
>
> >   * We like the syntax :)
>
> It is nice for C++ programmers, but Python programmers at
> least are
> very much more comfortable without the brackets.


>
> >   * We can remove the lua_State* parameter from
> >     all calls to def()/class_()
>
> I'm not sure what that is.  We handle global state in
> Boost.Python by
> simply keeping track of the current module ("state") in a
> global
> variable.  Works a treat.

As pointed out lua can handle multiple states, so using
global variabels doesn't strike me as a very good solution.

>
> > What do you consider the downsides to be?
>
> In addition to what I cited above,
>
> a. since methods and module-scope functions need to be
> wrapped
>    differently, you need to build up a data structure
> which stores the
>    arguments to def(...) out of the comma-separated items
> with a
>    complex expression-template type and then interpret
> that type using
>    a metaprogram when the operator[]s are applied.  This
> can only
>    increase compile times, which is already a problem.

We don't build a complex expression-template, instead we
build a list of objects with a virtual method to commit that
object to the lua_State. This doesn't increase compile
times.

>
> b. You don't get any order-of-evaluation guarantees.
> Things like
>    staticmethod() need to operate on an existing function
> object in the
>    class' dictionary
>
> [http://www.boost.org/libs/python/doc/v2/class.html#class_
> -spec-modifiers]
>    and if you can't guarantee that it gets executed after
> a def()
>    call you need to further complicate your expression
> template to
>    delay evaluation of staticmethod()

As we don't build a expression template, I don't think this
is an issue.

>
> I guess these two are essentially the same issue.
>
> >> > Also, we don't have a type-converter registry; we
> make all
> >> > choices on what converter to use at compile time.
> >>
> >> I used to do that, but it doesn't support
> >> component-based-development has other serious problems.
>  Are you
> >> sure your code is actually conformant?  When converters
> are
> >> determined at compile-time, the only viable and
> conformant way
> >> AFAICT is with template specializations, and that means
> clients
> >> have to be highly conscious of ordering issues.
> >
> > I think it's conformant, but I wouldn't swear on it.
> > We strip all qualifiers from the types and specialize on
> >
> >   by_cref<..>
> >   by_ref<..>
> >   by_ptr<..>
> >   by_value<..>
> >
> > types.
>
> How do people define specialized converters for particular
> types?

This isn't finished, but currently we do:

yes_t is_user_defined(by_cref<my_type>);
my_type convert_from_lua(lua_State*, by_cref<my_type>);

something like that..

>
> > It works on all compilers we have tried it on (vc 6-7.1,
> > codewarrior, gcc2.95.3+, intel).
>
> Codewarrior Pro8.x, explicitly using the '-iso-templates
> on' option?
> All the others support several common nonconformance bugs,
> many of
> which I was exploiting in Boost.Python v1.

I haven't tried with -iso- option, I'll try it when i get
home. We do not however use the bug you where exploiting i
bpl.v1 (i assume you are referreing to friend templates?).

>
> > For us it doesn't seem like an option to dispatch the
> converters at
> > runtime, since performance is a really high priority for
> our users.
>
> What we're doing in Boost.Python turns out to be very
> efficient, well
> below the threshold that anyone would notice IIUC.  Eric
> Jones did a
> test comparing its speed to SWIG and to my great surprise,
> Boost.Python won.

Lua is used a lot in game developement, and game developers
tend to care very much about every extra cycle. Even an
extra function call via a function pointer could make
difference for those users.

We like the generated bindings to be almost equal in speed
to one that is hand written.

(sorry for my late reply, my home connection is down for two
weeks..)

--
Daniel Wallin