Noisy when choosing T::operator Type() vs T::op const Type() const

Jason Merrill
Mon Sep 18 13:10:00 GMT 2000

The warning is intended to let people know about what I consider a rather
confusing rule: When considering which of the possible conversion ops and
constructors to use for a conversion, for the conversion ops you only look
at the conversion from the argument type (say T) to the type of the 'this'
argument to the conversion op.  (T* normally, T const * for a 'const'
member function).  So for a conversion from a non-const object, the
non-const conversion op is chosen regardless of whether the return type of
the op is better or worse.

I introduced the warning because at the time, it was possible for a
conversion from a derived class to beat a conversion to a better type which
was inherited from a base class.  That has since been fixed by tweaking the
overload resolution rules (again) such that all conversion ops are treated
as coming from the most derived class, so we only have trouble if there are
differences in cv-quals.

Similarly, when comparing a constructor and a conversion op, which one is
chosen depends on the cv-quals.  If we compare A::A(const B&) and
B::operator A(), the latter wins because it doesn't involve a qual
conversion.  If we compare A::A(B&) and B::operator A() const, the former
wins for the same reason.  In fact, the tweak above makes this case worse:
when comparing A::A(B&) and B::operator A() for converting from a type D
derived from B, the latter will be chosen because it's treated as a D
member function, whereas the former requires a base conversion.  This all
seems confusing to me; thus the warning.

Due to popular demand, in the development tree I've disabled this warning
if the return type of the winner can be converted to the return type of the
loser using a qualification conversion; that will silence the warning in
the case where people have complained about it (op char * vs. op const
char *).  This could go into 2.95.3 were there to be such a thing.

Do you have any suggestions for improving the wording of the warning?


More information about the Gcc-bugs mailing list