Re: enum operator overloading VC9 compiler bug?
Arno wrote:
compiling this snippet:
enum E {
e1
};
bool operator<=( E, E ) {
return false;
}
int main()
{
E e;
e<=e;
return 0;
}
produces
1>c:\users\schoedl\documents\visual studio 2008\projects
\test6\test6\test6.cpp(17) : error C2593: 'operator <=' is ambiguous
1> c:\users\schoedl\documents\visual studio 2008\projects
\test6\test6\test6.cpp(10): could be 'bool operator <=(E,E)'
1> or 'built-in C++ operator<=(E, E)'
1> while trying to match the argument list '(E, E)'
comp.lang.c++.moderated seems to think it is a compiler bug. Is it?
Looks like a bug to me, too. From C++ standard 13.3.1.2p3:
For a ... binary operator @ with a left operand of a type whose =
cv-unqualified version is T1 and a right operand of a type whose =
cv-unqualified version is T2, three sets of candidate functions, =
designated member candidates, non-member candidates and built-in =
candidates, are constructed as follows:
....
- The set of non-member candidates is the result of the unqualified =
lookup of operator@ in the context of the expression according to the =
usual rules for name lookup in unqualified function calls (3.4.2) except =
that all member functions are ignored...
- ... the built-in candidates include all of the candidate operator =
functions defined in 13.6 that, compared to the given operator, ...
- do not have the same parameter-type-list as any non-template =
non-member candidate.
The last clause should have removed built-in operator<= from =
consideration in your example.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not =
necessarily a good idea. It is hard to be sure where they are going to =
land, and it could be dangerous sitting under them as they fly overhead. =
-- RFC 1925