Re: Re: Conversion policies

At 17:20 2003-08-22, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
> >
> > Bad wording on my side, what I meant to say was that partial
> > ordering can't be worked around on non compliant compilers
> > when doing this.
>
>I noticed :(
>
>One thing I "discovered" when doing Boost.Python is that you can often
>work around those problems if your overload set is all returning the
>same type (see boost/python/detail/unwind_type.hpp).  If you can sink
>the type deduction one call layer deeper.  We probably discussed this
>already, though: you seem to be well-versed in all the awful tricks.

Right, it's hard (or rather impossible..?) to move the type deduction into 
another
layer in this case, because the return type depends on it.

> >>I guess I don't really understand the motivation, here.  Could you
> >>say a little more about why you want to distinguish those cases?
> >>Is there something wrong with the way Boost.Python does this now
> >>(whatever "this" is ;->)?
> >
> > Remember that in luabind we handle everything compile time. This is
> > our way of allowing compilers like vc6.5 to extract T from T& / T*. It
> > also help with partial ordering.
>
>FWIW, the "dynamic" binding of registrations at static init time in
>Boost.Python makes some of those kinds of problems go away, because
>you can unwind the type before lookup... but again, I don't know how
>much impact that has on this particular issue 'cause I'm not sure
>exactly what we're discussing.  Is this about how users will write
>their own from_xxx converters?

Yes, that is correct. This does have a significant impact on this since
very little type deduction will have to take place in the converters.

>I have two other remarks:
>
>1. In Boost.Python the way you convert to-python depends on how the
>    result is being used: the method is different for arguments to
>    wrapped C++ functions and results from Python callbacks.  Explicit
>    conversions with extract<...>() use one of those methods; I forget
>    which.

Ok, I'll have to look in the BPL source to understand exactly what this
means.

>2. If this is just an issue of user-customization, I am learning to
>    prefer not distorting interfaces for broken compilers.  I'd rather
>    ask those users to apply BOOST_TT_BROKEN_COMPILER_SPEC in order to
>    produce the neccessary specializations for us to work in one
>    uniform way.  I know that doesn't *directly* address partial
>    ordering, but I think you can usually transform all partial
>    ordering problems into partial specialization problems, can't you?

Yes, in this particular case we could just use a template parameter
to the converter to deduce the type, given that we don't care about
non conforming compilers.

template<int N>
struct my_policy : converter_generator_tag<N>
{
    template<class T>
    struct generate_converter
    {
       typedef my_converter<T> type;
    };
};

One important thing here is that we can't have any additional layers in
conversion process; the result from the converter must go directly to
the wrapped function. If it isn't obvious this is because we want to be
able to return temporaries when the function expects a const&.
This is also why it can be useful to deduce the T from const T&
in the converter function.

How would we use the BOOST_TT_BROKEN_COMPILER_SPEC macro
to provide specializations?

---
Daniel Wallin



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0