This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC-3.0: possible regression
- To: jan at etpmod dot phys dot tue dot nl
- Subject: Re: GCC-3.0: possible regression
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Wed, 4 Jul 2001 15:09:08 +1000
- Cc: gcc at gcc dot gnu dot org
- References: <3B41EB8B.6CB018D5@etpmod.phys.tue.nl>
On 03-Jul-2001, jan@etpmod.phys.tue.nl <jan@etpmod.phys.tue.nl> wrote:
> The following code compiles with 2.95.3, but not with 3.0. Before filing
> a bug report, I would like your opinion what the standard has to say
> about it (I did not find a previous related report). What's wrong: the
> code or 3.0?
>
> #include <cstddef>
> struct MyString
> {
> char operator [](size_t) const;
> char& operator [](size_t);
> operator const char*() const;
> };
>
> main()
> {
> MyString s;
> char c = s[0];
> return 0;
> }
>
> Compiler output follows:
>
> jan@gum03:/real-home/jan > g++ -c test.cpp
> test.cpp: In function `int main()':
> test.cpp:12: choosing `char& MyString::operator[](unsigned int)' over
> `operator[]'
> test.cpp:12: because worst conversion for the former is better than
> worst
> conversion for the latter
>
> I understand what's going on, but had expected the const-version of the
> []-operator to be chosen, like with 2.95.3.
Why would the const version of operator [] be chosen?
The non-const version is an equal match on the size_t argument,
and a better match on the `this' argument, since the object `s'
is not const. So I think 3.0 is correct here.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.