In article AA04691@hercules.iassf.easams.com.au, rjl@iassf.easams.com.au
writes:
>
>Surely it is ill-formed, since char is implementation defined as either
>unsigned char or signed char.
>:  S( char ) {
>...
>:  S( unsigned char ) {
>
>Which means that on some platforms this means something and on others
>it is a dupplicate definition.

No. Type "char" has the same repesentation as either "signed char" or
"unsigned char", but is a distinct type. You can overload on all three
types:
 int foo(char) { ... }
 int foo(signed char) { ... }
 int foo(unsigned char) { ... }

Similarly, type int often has the same representation as either type
short or type long, but it is a distinct type.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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. ]

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. ]

Hello there,

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 ?
  ;

}

my opinion is that the code is ok, and the compilers that think it is
ambiguous are wrong.

Your opinion sought

Regards
David Binderman MSc BSc    +44 1293 544 364       dcb@pncl.co.uk
      If only everything in life was as reliable as a Toyota
---
[ 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. ]