"William E. Aitken" <aitken@halcyon.com> writes:

>Consider the following (admittedly contrived) piece of code.
>My reading of the draft standard suggests that it should print 1
>and not 0, and at least one popular compiler agrees.   The point is
>that since e is of enum type, operator overloading resolution
>occurs for the instance of &e in the body of main.  There is
>a coercion from E to FOO (integral coercion to int, followed by a call of
>FOO::FOO(int)).   Because & has no built-in candidates this means that
>the global function operator &(FOO) is selected.   This increments y,
>where the built-in & would have left it as 0.

>Is it *really* the intent of the committee that a user function
>requiring a user coercion should be called, when the builtin function
>requires no coercion?

Thanks for posting this question. The current draft does say that for
address-of (and the comma operator) there are no built-in candidate
functions. That leads to the probably unexpected results of your
analysis. The C++ Commitee will be looking over those rules at
the next meeting.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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                             ]

Consider the following (admittedly contrived) piece of code.
My reading of the draft standard suggests that it should print 1
and not 0, and at least one popular compiler agrees.   The point is
that since e is of enum type, operator overloading resolution
occurs for the instance of &e in the body of main.  There is
a coercion from E to FOO (integral coercion to int, followed by a call of
FOO::FOO(int)).   Because & has no built-in candidates this means that
the global function operator &(FOO) is selected.   This increments y,
where the built-in & would have left it as 0.

Is it *really* the intent of the committee that a user function
requiring a user coercion should be called, when the builtin function
requires no coercion?

---- Start code -----------------------------------------------------

#include <stdio.h>  // yuck

int y = 0;

enum E {
 eBlah
};

E e;
E* pe = &e; // get address while we can...  no overloadings of & in scope yet.

struct FOO {
 int y;
 FOO(int x) : y(x) {};
};

E* operator &(FOO foo) {y++; return pe;}

int main(int argc, char**argv)
{
 E* pe;
 pe = &e;

 printf("%d\n", y);
 return 0;
}


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