🚀 go-pugleaf

In article WAA27727@eiger.pncl.co.uk, dcb@pncl.co.uk (David C Binderman)
writes:

Ignoring the several errors in this sample code, the comparison is not
ambiguous. You are comparing, in effect, the types
	R == enum

There are two viable functions:
1. built-in operator==(int,int)
2. operator==(char, const S&)
(None of the other built-in comparison "functions" could be called.)

Function 1 requires a user-defined conversion on the first argument and
a promotion on the second.

Function 2 requires a user-defined conversion on both arguments (plus
extra standard conversions which don't affect the analysis).

Thus, Function 1 is preferred, and there is no ambiguity.

There would be an ambiguity in choosing Function 2, since the enum could be
converted to an S by first converting it to a char or unsigned char. But
since Function 1 is unconditionally preferred, it doesn't matter how many
potential ambiguities exist in using functions which are not preferred.

---
Steve Clamage, stephen.clamage@eng.sun.com


>Following on from an outbreak of compiler disagreement,

>// is this ambiguous or not ?

>// workaround is to use cast on lhs

>#include <iostream.h>

>class S
>{

>public:
>	S( char ) {
>		cerr << "S::S char\n";
>	};
>	
>	S( unsigned char ) {
>		cerr << "S::S char\n"
>	};
>};

>operator == ( char, const S &)
>{
>	cerr << "operator ==\n";
>};

>class R
>{
>public:
>	enum { a, b, c};
>	operator int () {
>		cerr << "R::operator int\n";
>	};
>};

>int
>main()
>{
>	R z;
>	// if ((int) z == R::a)
>	// workaround line
>	if (z == R::a)
> // ambiguous ?
>		;
>}
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]