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

[Daniel Wallin]

> "dalwan01" <dalwan01 at student.umu.se> writes:
>
> >> "dalwan01" <dalwan01 at student.umu.se> writes:
> >>
> >> >>
> >> >> 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:
> >> >> >>
> >> >> >> > 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.
> >>
> >> I am not committed to the global variable approach nor
> am I opposed
> >> to the syntax.
>
> In fact, the more I look at the syntax of luabind, the
> more I like.
> Using addition for policy accumulation is cool.  The
> naming of the
> policies is cool.

It does increase compile times a bit though, but it
shouldn't matter that much.

>
> >> > This doesn't increase compile times.
> >>
> >> Good.  Virtual functions come with bloat of their own,
> but that's
> >> an implementation detail which can be mitigated.
> >
> > Right. The virtual functions isn't generated in the
> > template, so there is very little code generated.
>
> I don't see how that's possible, but I guess I'll learn.

We can generate the wrapper code in the template, and store
function pointers in the object instead of generating a
virtual function which generates the wrapper functions. I'm
not sure we do it that way though, been a while since I
looked at the code.

>
> >> >> > 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.
> >>
> >> I'm not really sure what the above means yet... I'm
> certainly
> >> interested in avoiding runtime dispatching if possible,
> so if this
> >> approach is viable for Boost.Python I'm all for it.
> >
> > I don't know if i fully understand the ordering issues
> you
> > mentioned. When we first implemented this we had
> converter
> > functions with this sig:
> >
> > T convert(type<T>, ..)
> >
> > This of course introduces problems with some compilers
> when
> > trying to overload for T& and T* and such. So we
> introduced
> > a more complex type<..>.. T& -> by_ref<T>, const T& ->
> > by_cref<T> etc.
>
> The ordering issues basically have to do with the
> requirement that
> classes be wrapped and converters defined before they are
> used,
> syntactically speaking.  That caused all kinds of
> inconveniences in
> BPLv1 when interacting classes were wrapped.  OTOH I bet
> it's possible
> to implicltly choose conversion methods for classes which
> you haven't
> seen a wrapper for, so maybe that's less of a problem than
> I'm making
> it out to be.

Ok. In BPLv1 you generated converter functions using friend
functions in templates though, and this was the cause for
these ordering issues?

>
> >> How will this work when multiple extension modules need
> to
> >> manipulate the same types?
> >
> > I don't know. I haven't given that much thought. Do you
> see
> > any obvious issues?
>
>
> Hmm, maybe I'm on drugs.  The biggest problems in BPLv1 in
> this area
> were because the converters for a given class were
> generated,
> essentially, by its class_<...> instantiation.  But I have
> already
> said that from-python conversion for a given wrapped class
> is normally
> done statically.
>
> User-defined converters still need to be exposed to all
> the extensions
> which use the types, somehow.  It would be better not to
> replicate
> that code.

I haven't thought about that at all. But it's a good point,
and it's impossible to not replicate the code with static
dispatch.

> >> How do *add* a way to convert from Python type A to C++
> type B
> >> without masking the existing conversion from Python
> type Y to C++
> >> type Z?
> >
> > I don't understand. How are B and Z related? Why would a
> > conversion function for B mask conversions to Z?
>
> Sorry, B==Z ;-)

Ah, ok. Well, this isn't finished either. We have a
(unfinished) system which works like this:

template<>
struct implicit_conversion<0, B> : from<A> {};
template<>
struct implicit_conversion<1, B> : from<Y> {};

Of course, this has all the problems with static dispatch as
well..

>
> >> > 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.
> >>
> >> I'm not convinced yet.  Just adding a tiny bit of lua
> code next to
> >> any invocation of a wrapped function would typically
> consume much
> >> more than that.
> >>
> >> > We like the generated bindings to be almost equal in
> speed to one
> >> > that is hand written.
> >>
> >> Me too; I just have serious doubts that once you factor
> in
> >> everything else that you want going on (e.g. derived
> <==> base
> >> conversions), the ability to dynamically register
> conversions has a
> >> significant cost.
> >
> > You might be right. I'll investigate how runtime
> dispatch
> > would affect luabind the next couple of days, in
> particular
> > I will look at what this would do to our policy system.
>
> OK.  Incidentally, I find much of what you're doing very
> appealing,
> and I think that if we could find a way to share a lot of
> technology
> it would be fantastic.

I think so too. I'm looking around in BPL's conversion
system now trying to understand how I incorporate it in
luabind.

--
Daniel Wallin