Re: Re: Conversion policies

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

I'm not 100% sure on how boost.python handles "this", but IIRC it's
handled just by passing the unmodified type as a class template
parameter, is this correct? Something like:

template<class T>
struct rvalue_converter_etcetc
{
    T operator()(..) {}
};

I don't know what's wrong with it, but at least I guess it isn't as flexible.

---
Daniel Wallin



-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104