🚀 go-pugleaf

Before my main question: I use the term ill-formed below because
that is what the WP used.  Is an ambiguous call ill-formed?  I am
not familiar with this term and so I want to make sure the compiler
is required to issue some error...

When figuring out which operator to use is any precedence given to
operators defined in the class?  Basically my interpretation of the
WP of the following situation is that the "function call" is ill-formed.

        class A {
                ...
                A(int);
                operator int();
                bool operator =3D=3D(A& a);
                ...
        };

        void func()
        {
                A a;
                bool result =3D
                        (a =3D=3D 4);       // ill-formed?

The candidate functions are:

        bool A::operator=3D=3D(A& a);           // 1
        bool built-in::operator(int, int);      // 2

(1) requires a user-defined conversion (A::A(4)) on its second
argument.  (2) requires a user-defined conversion (a.A::operator int())
on its first argument.

Someone in another newsgroup was inquiring as to whether their
compiler's selection of the member operator was a bug.  My first
guess was that it was not.  I think I based the guess on the fact
that the built-in operators would exist in the global scope and that
therefore the definition of the member operator would hide the global
built-in version.  It seems now that this was a bad assumption and
that, unless the explicit function syntax is used, no hiding of
operators takes place.

Do I have things straight now? (Zooming around the WP with regards to
overload resolution tends to make me feel less confident in what I
think I found.)

Overload resolution can probably not be made any simpler and that is
too bad because right now its pretty complex.  The scoping rules for
normal functions do make things less complex though.  That is, while
designing, section 13 in it full "glory", is probably too much to
effect my decisions.  Instead I'll probably use the normal scoping
rules.  It also helps that I avoid Class([integral-type]) and
Class::operator [integral-type]() like the plague. :)

As a side note: there is a typo in the WP (13.3.1.2 (over.match.oper)
paragraph 7

        struct A {
                operator int();
        };
        A operator+(const A&, const A&);
        void m() {
                A a, b;
                a + b;        // a.operator+(b) chosen over int(a) + int(b)
        }

the "a.operator+(b)" should be "operator+(a, b)".

Chris.



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