Topic: Operator Ambiguity with Basic Types : need ARM interpretations


Author: rfg@netcom.com (Ronald F. Guilmette)
Date: Sat, 20 Nov 1993 09:05:15 GMT
Raw View
In article <CGA4w2.1AK@undergrad.math.uwaterloo.ca> anicolao@watcgl.uwaterloo.ca (Alex Nicolaou) writes:
>// example starts
>class ffloat
>{
>public:
>float x;
>
>ffloat(float newx) { x = newx; }
>
>operator float() const
>{
>return x;
>}
>};
>
>main()
>{
> ffloat t(0),u(0);
> t.x = 1.5;
> u = t + 0.5;
>}
>// example ends
>
>The final statement in this example is intended to cast t to a double and
>perform the addition. My reading of the ARM lead to no clear conclusion for
>this case; ATT3 says 'no problem', Borland3.1 ditto, but Watcom (recently
>aquired, of course :-) gives the error that it can't decide between
>operator+(double, double) and operator+(float, float).

This is a rather tricky case, but I believe that Watcom is in error here,
and that the code should be accepted.

It seems that the Watcom compiler is effectively asserting that there are
built-in operators like `operator+(double,double)' and `operator+(float,float)'
but it doesn't feel that there are any such things as "mixed-mode" built-in
floating point operators such as `operator(float,double)'.

That issue hasn't been formally decided by X3J16 yet, but I (for one) would
tend to agree with Watcom's interpretation on this point.

Note however that even if one assumes that no mixed-mode built-in floating-
point operators exist, it would still seem completely reasonable for the
compiler to implicitly convert `t' (via the user-defined conversion operator)
to type `float' and then further convert that result (again, implicitly) to
type double.  That would then allow the built-in `operator+(double,double)'
to be called as the "best matching" function.  (It is this last conversion
that the Watcom compiler seems to have missed.)

>(I wonder how it adds 0.1 + 0.3? ;-).

That is an entirely different case.  In that case, you are adding a type
`double' operand to another type `double' operand... and there can be no
doubt about how that should be done!

>I'm looking for exact pointers to the ARM that specify the correct answer

Good luck.

(Follow-ups to comp.std.c++ please.)

--

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