🚀 go-pugleaf

In article <r47myjasnx.fsf@erawan.cognex.com> Michael Cook
<mcook@cognex.com> writes:

|> Does the standards committee consider this code ambiguous:

|>   struct X;
|>   struct Y
|>   {
|>       operator X*();
|>       operator const X*() const;
|>   };
|>   void* f(Y y)
|>   {
|>       return y; //10
|>   }

According to the draft, I believe that there is no ambiguity.  The
const function cannot be called, so it should not even be considered.
I think that the ARM was ambiguous as to whether this was ambiguous.

|> A couple compilers (different vendors) say it /is/ ambiguous, but I can't
|> see why.  Shouldn't the compiler decide that `y.operator X*()' is a better
|> choice because `y' is not `const'--just as for other overload resolution?

|> (In particular, gcc says
|>   x.C:10: ambiguous conversion from `Y' to `void *'
|>   x.C:10:   candidate conversion functions include `const X *' and `X *'
|> .)

Historically, g++ has been rather lax in enforcing const.  Although
recent versions have improved greatly, this may be just something that
they haven't gotten around to correcting yet.  Historically, the
original author of g++ disagreed with Stroustrup in several points,
and since there wasn't a standard...  The older versions of g++ had
their own syntax for placement new, different rules for function
hiding, and ignored const.  (They also had a lot of errors, but the
above represent a conscious decision to do things differently than
cfront, rather than errors.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]