This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/3747
- To: "'jan at etpmod dot phys dot tue dot nl'" <jan at etpmod dot phys dot tue dot nl>, "'gcc-gnats at gcc dot gnu dot org'" <gcc-gnats at gcc dot gnu dot org>, "'gcc-prs at gcc dot gnu dot org'" <gcc-prs at gcc dot gnu dot org>, "'martin dot gerbershagen at icn dot siemens dot de'" <apataki at apataki dot dhs dot org>, "'gcc-bugs at gcc dot gnu dot org'" <gcc-bugs at gcc dot gnu dot org>, "'nobody at gcc dot gnu dot org'" <nobody at gcc dot gnu dot org>
- Subject: Re: c++/3747
- From: "Rosen, Hyman" <Hyman dot Rosen at kbcfp dot com>
- Date: Fri, 19 Oct 2001 16:25:35 -0400
To recap, given the code
struct A {
char operator[](unsigned) const;
operator const char*() const;
} s;
char c = s[0];
gcc reports ambiguity in the choice of operators,
which the original reporter thinks is a bug. In fact,
gcc is correct, and the construct is ambiguous.
The analysis begins in 13.3.1.2. Because s has class
type, we come up with two candidates for the expression
s[0]. The first is the member operator[], which upon
including the object for overload resolution (13.3.1/2)
looks like the call
A::operator[](A, unsigned)
The second candidate, which we derive from 13.3.1.2/3 and
13.3.3.1 is the built-in operator (13.6/13)
operator[](const char *, ptrdiff_t)
Now, given the first candidate, the first operand requires
no conversion, while the second does, since the type of 0
is not unsigned. Given the second candidate, the first operand
requires a conversion but the second does not if ptrdiff_t is
a synonym for int. So the compiler correctly flags the expression
as ambiguous.
The proper response to this code is to say "don't do that" and
to once again reflect on why conversion operators are bad, and
why subscript operators should take int and not unsigned.
Unfortunately, this is also the code generated by CORBA
IDL-to-C++ compilers, so you'll probably see a lot of this.