Valentin Bonnard <bonnardv@pratique.fr> writes:

 >inpact3 <inpact3@clr34el.der.edf.fr> writes:
 >
 >>   class string
 >>   {
 >>     private:
 >>       class Dummy {};
 >>       operator Dummy * () const;   //-- undefined
 >
 >[...]
 >
 >>       operator const char * () const { ... }
 >>         string str ("foo");
 >>         cout << str;          //-- Here : ambiguity for xlC
 >>   }
 >
 >[...]
 >
 >> For the "cout << str" call,  there is two viable functions :
 >>
 >>   ostream::operator<< (const char *)       func1
 >>   ostream::operator<< (const void *)       func2
 >>
 >> For the first one, the implicit conversion sequence is :
 >>
 >>   string --> const char *       (user-defined)
 >>
 >> For func2, two implicit conversion sequences exist :
 >>
 >>   string --> const char * -> const void *    (user-defined)
 >>   string --> Dummy * -> const void *         (user-defined)
 >
 >I believe that overloading resolution is done between
 >all these possible cs. But as you say, some can't be
 >compared, so overloading resolution fails.

I'm pretty sure that's not correct.  The WP says that overloading resolution
is done between each viable functions, not between each possible implicit
conversion sequence.  A compiler must pick one implicit conversion
sequence for each viable function, and then compare those.

 >The call is ambiguous.

No, I think the original poster was correct: it is unspecified whether
or not the call is ambiguous; it depends on which ICS the compiler picks :-(

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi,

A few weeks ago, I posted a message about a possible bug in CD2.
Alas, it was mid-august and apparently, gurus were on the beach ;)
I did not get any answer, either showing my error or confirming
the bug. So, being stubborn, i decided to post again.

The problem arose when i tried to compile the following code (that
demonstrates a trick which should reduce implicit conversions danger)
with both Sun C++ 4.0.1 (and 4.1) and xlC (for AIX 4.1) compilers :

Sun CC compiles ok but xlC complains about an ambiguity error on
the last line. I tried to find which compiler was wrong by reading
carefully the CD2. My conclusion is rather strange : if i did not
misunderstand something, both are right !!!

//-- Code example:
//----------------------------------------------------------------
  class string
  {
    private:
      class Dummy {};
      operator Dummy * () const;   //-- undefined
      //-- This dummy conversion function shall force compile
      //-- time errors when the class string is used in such
      //-- silly constructs as :
      //
      //--   string str("foo");
      //--   if (str) delete str;

    public:
      operator const char * () const { ... }
      ...
  };

  main()
  {
        string str ("foo");
        cout << str;          //-- Here : ambiguity for xlC
  }
//----------------------------------------------------------------


Let's try an explanation...

For the "cout << str" call,  there is two viable functions :

  ostream::operator<< (const char *)       func1
  ostream::operator<< (const void *)       func2

For the first one, the implicit conversion sequence is :

  string --> const char *       (user-defined)

For func2, two implicit conversion sequences exist :

  string --> const char * -> const void *    (user-defined)
  string --> Dummy * -> const void *         (user-defined)

Neither is better than the other (two user-defined sequences can
be compared only if they use the same conversion function. See
[over.ics.rank] alinea 3).

In this case, the compiler shall pick one of them randomly and,
if the viable function that use it (func2) is found as the best,
the call will be ill-formed (see [over.best.ics] alinea 10).

Scenario 1 : the compiler picks the first conversion sequence
--------------------------------------------------------------

To find the best viable function, the compiler tries to compare the
implicit conversion sequences for all arguments (see [over.match.best]).

In this case, ICS1(func1) is not worse than ICS1(func2) and
ICS2(func1) is better than ICS2(func2) :

ICS2(func1) = string --> const char *
ICS2(func2) = string --> const char * -> const void *

According to [over.ics.rank] alinea 3, one user-defined sequence is
better than another if :
- they both use the same conversion function   (that's the case)
- the second standard conversion sequence of the former has a better
rank than the latter (here, we have "exact match" vs. "conversion").

So, func1 is the better than func2. The call is not ill-formed because
func2 has not been selected (see [over.best.ics] alinea 10).

Scenario 2 : the compiler picks the second conversion sequence
---------------------------------------------------------------

In this case, ICS2(func1) is neither better nor worse than ICS2(func2)
because they don't use the same conversion function.

Therefore, func1 is neither better nor worse than func2.
The call is ill-formed.



So, where is my error ? I can't imagine that the draft let a compiler
choose between alternatives, knowing that only one will make a program
ill-formed.


        Thanks for reading,
        Jerome CHAROUSSET
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

inpact3 <inpact3@clr34el.der.edf.fr> writes:

>Sun CC compiles ok but xlC complains about an ambiguity error on
>the last line. I tried to find which compiler was wrong by reading
>carefully the CD2. My conclusion is rather strange : if i did not
>misunderstand something, both are right !!!

As far as I can tell your analysis is correct.

>I can't imagine that the draft let a compiler
>choose between alternatives, knowing that only one will make a program
>ill-formed.

Stranger things have happened before...

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

inpact3 <inpact3@clr34el.der.edf.fr> writes:

>   class string
>   {
>     private:
>       class Dummy {};
>       operator Dummy * () const;   //-- undefined

[...]

>       operator const char * () const { ... }
>         string str ("foo");
>         cout << str;          //-- Here : ambiguity for xlC
>   }

[...]

> For the "cout << str" call,  there is two viable functions :
>
>   ostream::operator<< (const char *)       func1
>   ostream::operator<< (const void *)       func2
>
> For the first one, the implicit conversion sequence is :
>
>   string --> const char *       (user-defined)
>
> For func2, two implicit conversion sequences exist :
>
>   string --> const char * -> const void *    (user-defined)
>   string --> Dummy * -> const void *         (user-defined)
>

I believe that overloading resolution is done between
all these possible cs. But as you say, some can't be
compared, so overloading resolution fails.

The call is ambiguous.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]