public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: austern@apple.com
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: c++/8316: Confusing diagnostic for code that misuses conversion operators
Date: Thu, 24 Oct 2002 08:26:00 -0000	[thread overview]
Message-ID: <20021024152605.29273.qmail@sources.redhat.com> (raw)

The following reply was made to PR c++/8316; it has been noted by GNATS.

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:


             reply	other threads:[~2002-10-24 15:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-24  8:26 austern [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-03-19 18:24 jason
2003-03-18 20:36 jason
2002-12-19 17:16 bangerth
2002-10-22 21:36 austern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021024152605.29273.qmail@sources.redhat.com \
    --to=austern@apple.com \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).