In article <ercC8HIM2.MKo@netcom.com> erc@netcom.com (Eric Smith) writes:
>
>If an operator is applied to an object whose class has a conversion to
>a built-in type which can be used with that operator, but the class also
>has the operator overloaded as a member function, the rules for deciding
>whether it's ambiguous between those two choices don't seem very clear.

Ther aren't... and as it happens, I raised this very same issue with x3j16
recently.

For the time being, there are no clear rules for deciding between built-in
and user-defined operators (when both seem to be reasonable possibilities).

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

If an operator is applied to an object whose class has a conversion to
a built-in type which can be used with that operator, but the class also
has the operator overloaded as a member function, the rules for deciding
whether it's ambiguous between those two choices don't seem very clear.

For example, if I have a class String which has operator+=(char) and
also has operator int(), how do the rules apply to string+='0'+n
which gives the member operator an int argument or gives the built-in
operator a String and an int?  The String can be converted to int to
make it int+=int, or the int can be converted to char, allowing use
of String::operator+=(char).  The latter seems much better, but is
it?  The ARM seems to disagree.  What is the exact rule for this case?

My interpretation of the ARM says it's ambiguous.  The member vs
built-in versions of the operator are equivalent to two functions,
operator+=(String,char) and operator+=(int,int).  Each of these
two functions requires conversion of a different argument, and that
means they are ambiguous regardless of how drastic those conversions
may or may not be.  But is that interpretation really correct?