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

David Abrahams dave at boost-consulting.com
Fri Jun 20 14:13:35 CEST 2003


I just love how GNUs is able to straighten out that nasty Outlook
(Express) wrapping.  Unfortunately it looks like you're using
webmail, or you could use OE-QuoteFix :(

"Daniel Wallin" <dalwan01 at student.umu.se> writes:

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

What, overloading '+'?  I don't think it's significant.

> but it shouldn't matter that much.

Agreed.

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

Well, IIUC, that means you have to treat def() the same when it
appears inside a class [...] as when it's inside a module [ ... ],
since there's no delayed evaluation.

    ah, wait: you don't use [ ... ] for class, which gets you off
    the hook.

    but what about nested classes?  Consistency would dictate the
    use of [ ... ].


> I'm not sure we do it that way though, been a while since I looked
> at the code.

OK.

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

That was one factor.  The other factor of course was that each class
which needed to be converted from Python used its own conversion
function, where a generalized procedure for converting classes will do
perfectly well.

There is still an issue of to-python conversions for wrapped classes;
different ones get generated depending on how the class is "held".
I'm not convinced that dynamically generating the smart pointer
conversions is needed, but conversions for virtual function
dispatching subclass may be.

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

Right.  BPLv1 used a nonuniform system of explicit importing
converters from other modules (thanks, Ralf!) but we went to uniform
dynamic dispatching for v2.

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

And with multiple implicit conversions being contributed by multiple
people.  Also note that in many environments there's no guarantee that
different extension modules won't share a link namespace, so you have
to watch out for ODR problems.

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

I am not convinced I got it 100% right.  You've forced me to think
about the issues again in a new way.  It may be that the best answer
blends our two approaches.

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





More information about the Cplusplus-sig mailing list