Re: Conversion policies

Daniel Wallin <[email protected]> writes:

> At 14:53 2003-08-19, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > Given a conversion policy which handles conversions
>> > xxx -> C++, what should be passed to the converter
>> > function so that it can deduce the type?
>> >
>> > struct my_converter_policy
>> > {
>> >     template<class T>
>> >     T convert(const param_type&, ...<T>);
>> >                                  ^^^^^^ what goes here?
>> > };
>> >
>> > The simplest approach would be to just pass a
>> > boost::type<T>, but this means partial ordering
>> > won't work.
>>
>>Why?  Comeau accepts this:
>>
>>     template <class T> struct type {};
>>
>>     template <class T>
>>     int* convert(int, type<T>);
>>
>>     template <class T>
>>     long* convert(int, type<T*>);
>>
>>     int* x = convert(0, type<int>());
>>     long* y = convert(0, type<char*>());
>
> 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.

> Obviously partial ordering will still work on
> nice conforming compilers like Comeau. :)
>
>> > Also, IIRC, trying to deduce T from
>> > type<const T&> results in an ICE on VC6.5.
>>
>>vc6.5 compiles this just fine:
>>
>>     template <class T> struct type {};
>>
>>     template <class T>
>>     int* convert(int, type<T>);
>>
>>     int* x = convert(0, type<int const&>());
>
> Yes, but that doesn't accomplish what I said. This will ICE vc6.5:
>
>    template<class T>
>    struct type {};
>
>    template<class T>
>    void f(type<T&>);
>
>    f(type<int&>());
>
> Which means T can't be extracted from cv T* cv T& types on that
> platform.
>
>>Of course, if you're concerned about partial ordering, vc6.5/7 doesn't
>>support it; you have to "help", and the ways I know of helping do
>>seem to produce ICEs with vc6.5 when combined with type<...>.
>>
>>Why don't we go with class specialization, anyway?
>>
>><snip code>
>
> Because that would mean compilers which can't handle partial
> specialization would be screwed if you want to extract something
> more useful than just the type in the function signature.
>
>> > FWIW, in luabind, we handle this by decorating the
>> > type:
>> >
>> >    T           by_value<T>
>> >    T&          by_reference<T>
>> >    const T&    by_const_reference<T>
>> >    T*          by_pointer<T>
>> >    const T*    by_const_pointer<T>
>>
>>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?

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.

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?

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



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