Prateek wrote:
> > Your requirement is very specific -- some proxy classes want to be
> > convertible to any type that the proxy subject is convertible to.
> > Instead of changing the language, try coding that explicitly.
> >
> >
> > template<typename Subject>
> > class Proxy
> > {
> >     Subject subject;
> > public:
> >    template<typename Convertible>
> >    operator Convertible()
> >    {
> >        return subject;
> >    }
> >
> >
> > };
>
> That's precisely where the problem lies. Normally one wants the proxy
> class to be "transparent", i.e. in this case someone expecting a T
> should be satisfied with a Proxy<T>. However, in this conversion from
> Proxy<T> to T, we have already "used up" our quota of 1 user-defined
> conversion. So if the client code relies on the T being implicitly
> converted to something else, it will fail. This problem would not arise
> if the conversion in the proxy class had been marked as "trivial".

Try it out.  I think you'll be surprised by how the code behaves.  For
example, this code compiles:

struct A { };
struct B {
    operator A() { return A(); }
};
void TakesA(A) { }

void testChainedCast() {
    B b;
    TakesA(b);
    Proxy<B> p;
    TakesA(p);
}

Note that the templated conversion operator in Proxy<T> doesn't
necessarily convert directly to T.  It converts to any type, assuming
that T can be cast to that type.

-- chad

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chad wrote:
> Prateek wrote:
>
>>While reading "More Effective C++", I realised that the rule that at
>>most 1 user-defined conversion can be applied in a sequence of implicit
>>conversions is too restrictive in some cases, eg. while using proxy
>>classes. So maybe there should be a way to mark a conversion function
>>(both 1-arg ctors and conversion operators) as a "trivial" conversion,
>>and the rule changed that at most 1 *non-trivial* conversion function
>>be used. This can be achieved without sacrificing backward compatibily
>>by using the auto keyword to indicate a "trivial" conversion.
>
>
> Allowing implicit conversions to be chained sounds like it would be a
> tough requirement for compiler vendors.

    It's implementatable but undesirable.  PL/I tried
to do implicit conversions whenever possible, and this
often resulted in invisible errors.

    A related proposal that crops up occasionally is to allow
overloading on the return type. This creates a similar problem.

    (Amusingly, if you allow overloading on the return type and
insist that the compiler resolve chains of functions whenever possible,
the resulting mechanism may be Turing-equivalent, allowing
arbitrary computation at compile time.  This is probably not useful.)

        John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>    (Amusingly, if you allow overloading on the return type and
> insist that the compiler resolve chains of functions whenever possible,
> the resulting mechanism may be Turing-equivalent, allowing
> arbitrary computation at compile time.  This is probably not useful.)

On the other hand, if you allow no automatic conversions
then overloading on return type becomes easy to do, and
useful. That's what Ada does.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Your requirement is very specific -- some proxy classes want to be
> convertible to any type that the proxy subject is convertible to.
> Instead of changing the language, try coding that explicitly.
>
>
> template<typename Subject>
> class Proxy
> {
>     Subject subject;
> public:
>    template<typename Convertible>
>    operator Convertible()
>    {
>        return subject;
>    }
>
>
> };

That's precisely where the problem lies. Normally one wants the proxy
class to be "transparent", i.e. in this case someone expecting a T
should be satisfied with a Proxy<T>. However, in this conversion from
Proxy<T> to T, we have already "used up" our quota of 1 user-defined
conversion. So if the client code relies on the T being implicitly
converted to something else, it will fail. This problem would not arise
if the conversion in the proxy class had been marked as "trivial".

--                                                     --
To iterate is human, to recurse divine. -L. Peter Deutsch
--                                                     --

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

While reading "More Effective C++", I realised that the rule that at
most 1 user-defined conversion can be applied in a sequence of implicit
conversions is too restrictive in some cases, eg. while using proxy
classes. So maybe there should be a way to mark a conversion function
(both 1-arg ctors and conversion operators) as a "trivial" conversion,
and the rule changed that at most 1 *non-trivial* conversion function
be used. This can be achieved without sacrificing backward compatibily
by using the auto keyword to indicate a "trivial" conversion.

It is often advised that one should avoid implicit type conversion
functions and used named functions (eg. A::convert_to_B()) for the
same. The main reason why user-defined implicit type conversions are
advised to be avoided is that they are *implicit*. However, in a
template situation, if we want to convert a type A to a type B if
possible, there is no standard (I'm not referring to the Standard
here), accepted way of doing it. So IMHO we should be able to decalre
conversion operators explicit, just like 1-arg ctors. This too can be
achieved without breaking existing code. In other words, in the present
language, if we want to declare an implicit conversion from A to B, we
need access to A's declaration, or B's declaration. However, if we want
to declare an explicit conversion from A to B, we need B's declaration.
Why this asymmetery?

Prateek Karandikar

--                                                     --
To iterate is human, to recurse divine. -L. Peter Deutsch
--                                                     --

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Prateek wrote:
> While reading "More Effective C++", I realised that the rule that at
> most 1 user-defined conversion can be applied in a sequence of implicit
> conversions is too restrictive in some cases, eg. while using proxy
> classes. So maybe there should be a way to mark a conversion function
> (both 1-arg ctors and conversion operators) as a "trivial" conversion,
> and the rule changed that at most 1 *non-trivial* conversion function
> be used. This can be achieved without sacrificing backward compatibily
> by using the auto keyword to indicate a "trivial" conversion.

Allowing implicit conversions to be chained sounds like it would be a
tough requirement for compiler vendors.  Imagine that a user requests a
conversion from type A to type B.  The compiler would be required to
search for all type C's that A can convert to, and then check whether
they can be converted to type B (possibly via some other type D).  This
would require finding the shortest path among all classes in the type
system.

Your requirement is very specific -- some proxy classes want to be
convertible to any type that the proxy subject is convertible to.
Instead of changing the language, try coding that explicitly.

template<typename Subject>
class Proxy
{
    Subject subject;
public:
    template<typename Convertible>
    operator Convertible()
    {
        return subject;
    }
};

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]