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

[David Abrahams]

"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.

>> > 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.

>> >> > 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.

>> >> 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..
>>
>> I assume that means the user must define those two functions?
>> Where in the code must they be defined?
>
> Right. The user declares the first function and defines the
> other before binding functions that use the types.

Right.

>> 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.  Furthermore there are potential issues of creating objects
in one DLL and destroying them elsewhere.  These may be minor in
comparison, though.

Ralf, do you have any insight here?

>> 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 ;-)

>> > 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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com