Consider the following code fragment: struct X { char &operator[](char i); operator char *(); operator const char *() const; }; void f(X &x) { x[0] += 1; } Obviously this is bad practice, since x[0] should be interpreted too ways. The compiler ought to tell the programmer that he/she is doing something wrong. The compiler does do that. However, the diagnostic is so confusing that a user who would make this mistake is unlikely to be able to figure out what the compiler is saying. With 3.1 and 3.2, the output is: bash-2.05$ /usr/local/gcc-3.1/bin/g++ -c foo.cc foo.cc: In function `void f(X&)': foo.cc:11: choosing `char& X::operator[](char)' over `operator[]' foo.cc:11: because worst conversion for the former is better than worst conversion for the latter foo.cc:11: choosing `char& X::operator[](char)' over `operator[]' foo.cc:11: because worst conversion for the former is better than worst conversion for the latter Note that (1) the warning is repeated; and (2) it doesn't get to the heart of the matter and tell the user that it's a bad idea to provide both operator* and operator[]. A user is unlikely to be able to understand the problem from reading this message. With 3.3 the behavior is exactly the same, except that 'warning' is replaced by 'error'. This is not an improvement. Release: 3.1, 3.2, pre-3.3 TOT Environment: Linux
From: austern@apple.com To: gcc-gnats@gcc.gnu.org Cc: Subject: c++/8316: Confusing diagnostic for code that misuses conversion operators Date: 23 Oct 2002 04:29:40 -0000 >Number: 8316 >Category: c++ >Synopsis: Confusing diagnostic for code that misuses conversion operators >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Tue Oct 22 21:36:00 PDT 2002 >Closed-Date: >Last-Modified: >Originator: austern@apple.com >Release: 3.1, 3.2, pre-3.3 TOT >Organization: >Environment: Linux >Description: Consider the following code fragment: struct X { char &operator[](char i); operator char *(); operator const char *() const; }; void f(X &x) { x[0] += 1; } Obviously this is bad practice, since x[0] should be interpreted too ways. The compiler ought to tell the programmer that he/she is doing something wrong. The compiler does do that. However, the diagnostic is so confusing that a user who would make this mistake is unlikely to be able to figure out what the compiler is saying. With 3.1 and 3.2, the output is: bash-2.05$ /usr/local/gcc-3.1/bin/g++ -c foo.cc foo.cc: In function `void f(X&)': foo.cc:11: choosing `char& X::operator[](char)' over `operator[]' foo.cc:11: because worst conversion for the former is better than worst conversion for the latter foo.cc:11: choosing `char& X::operator[](char)' over `operator[]' foo.cc:11: because worst conversion for the former is better than worst conversion for the latter Note that (1) the warning is repeated; and (2) it doesn't get to the heart of the matter and tell the user that it's a bad idea to provide both operator* and operator[]. A user is unlikely to be able to understand the problem from reading this message. With 3.3 the behavior is exactly the same, except that 'warning' is replaced by 'error'. This is not an improvement. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted:
State-Changed-From-To: open->analyzed State-Changed-Why: Confirmed. Apart from the unnecessary duplication of error messages (where does this come from, this is not even a template which would be processed in two phases?), I can only think of telling that X::operator[] (char) is chosen over ::operator[] (whatever) (note the :: at the beginning). Matt, what better message do you have in mind? I think it is not so obvious what to say here. W. (Ah, and having an index operator that takes a character instead of an integer is an abuse as well :-)
Responsible-Changed-From-To: unassigned->jason Responsible-Changed-Why: mine
From: jason@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: c++/8316 Date: 19 Mar 2003 18:18:07 -0000 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_2-branch Changes by: jason@gcc.gnu.org 2003-03-19 18:18:07 Modified files: gcc/cp : ChangeLog call.c Log message: PR c++/8316, c++/9315, c++/10136 * call.c (joust): Improve wording. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.2685.2.114.2.73&r2=1.2685.2.114.2.74 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.307.2.6.4.3&r2=1.307.2.6.4.4
From: jason@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: c++/8316 Date: 19 Mar 2003 18:18:16 -0000 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: jason@gcc.gnu.org 2003-03-19 18:18:16 Modified files: gcc/cp : ChangeLog call.c Log message: PR c++/8316, c++/9315, c++/10136 * call.c (joust): Improve wording. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.91&r2=1.3076.2.92 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.341.2.14&r2=1.341.2.15
From: jason@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: c++/8316 Date: 19 Mar 2003 18:19:53 -0000 CVSROOT: /cvs/gcc Module name: gcc Changes by: jason@gcc.gnu.org 2003-03-19 18:19:53 Modified files: gcc/cp : ChangeLog call.c Log message: PR c++/8316, c++/9315, c++/10136 * call.c (print_z_candidate): Split out from... (print_z_candidiates): ...here. (joust): Use it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3284&r2=1.3285 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.369&r2=1.370
State-Changed-From-To: analyzed->closed State-Changed-Why: message improved
From: jason@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: c++/8316 Date: 21 Mar 2003 07:12:50 -0000 CVSROOT: /cvs/gcc Module name: gcc Changes by: jason@gcc.gnu.org 2003-03-21 07:12:50 Modified files: gcc/testsuite/g++.old-deja/g++.ext: overload1.C Added files: gcc/testsuite/g++.dg/overload: new1.C Removed files: gcc/testsuite/g++.old-deja/g++.other: new2.C Log message: PR c++/8316, c++/9315, c++/10136 * call.c (print_z_candidate): Split out from... (print_z_candidiates): ...here. (joust): Use it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/new1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.ext/overload1.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.other/new2.C.diff?cvsroot=gcc&r1=1.4&r2=NONE
*** Bug 13089 has been marked as a duplicate of this bug. ***
Hello, I use g++ 3.3.3 to compile my application, and I encountered a problem : src/OpePreparator.cc:2075: error: ISO C++ says that `int Ptr<T>::operator!=(const T*) const [with T = C_OPL::Header_att]' and ` operator!=' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter It seems that this kind of problem is known in the GCC database as the 13089 bug (duplicate of 8316) Can you confirm me in which release this bug is fixed ? Thank you a lot