public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@markmitchell.com>
To: bredelin@ucsd.edu
Cc: egcs@cygnus.com, Jason Merrill <jason@cygnus.com>
Subject: PATCH for Re: New c++ bug with conversion operators?
Date: Mon, 25 May 1998 13:43:00 -0000	[thread overview]
Message-ID: <199805251839.LAA21105@mail.earthlink.net> (raw)
In-Reply-To: <3550C34B.B5D0BAA3@ucsd.edu>

  struct string
  {
    char* location;
    int length;

    operator const char*() const{return location;}
    /*  operator const char*() {return location;} */
    operator char*() {return location;}
  };

  main() {
    int i;
    string s1;
    const string s2=s1;

    i=strlen(s1);
    i=strlen(s2);
  }
  --------------end test.C--------------
  Here is the text of the warnings:
  telomere:~/devel/Psh.0.4.6.8> make test
  g++ -fno-rtti -fno-exceptions -Wall -g -O13 -DNDEBUG -mpentiumpro
  -I../include -fno-rtti -fno-exceptions   test.C   -o test
  test.C: In function `int main()':
  test.C:16: warning: choosing `string::operator char *()' over
  `string::operator const char *() const'
  test.C:16: warning:   for conversion from `string' to `const char *'
  test.C:16: warning:   because conversion sequence for `this' argument is
  better
  test.C:16: warning: choosing `string::operator char *()' over
  `string::operator const char *() const'
  test.C:16: warning:   for conversion from `string' to `const char *'
  test.C:16: warning:   because conversion sequence for `this' argument is
  better

Actually, g++ is doing the right thing here.  The overloading rules 
say (in [over.match.conv]):

  The argument list has one argument, which is the initializer expres-
  sion.  [Note: this argument will be compared against the implicit
  object parameter of the conversion functions.  ]

So, the fact that `s1' is not const does matter.  This is somewhat
surprising behavior, which is why g++ warns.

There's no reason for it to warn twice, though.  (And that might have
confused into thinking the second warning is about `s2', which it
isn't).  Jason, is the following patch OK?

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

1998-05-25  Mark Mitchell  <mark@markmitchell.com>

	* call.c (tourney): Don't do any extra comparisons.

Index: call.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/cp/call.c,v
retrieving revision 1.80
diff -c -p -r1.80 call.c
*** call.c	1998/05/24 23:55:15	1.80
--- call.c	1998/05/25 18:36:24
*************** tourney (candidates)
*** 4389,4394 ****
--- 4389,4395 ----
  {
    struct z_candidate *champ = candidates, *challenger;
    int fate;
+   int champ_compared_to_predecessor = 0;
  
    /* Walk through the list once, comparing each current champ to the next
       candidate, knocking out a candidate or two with each comparison.  */
*************** tourney (candidates)
*** 4405,4423 ****
  	      champ = challenger->next;
  	      if (champ == 0)
  		return 0;
  	    }
  	  else
! 	    champ = challenger;
  
  	  challenger = champ->next;
  	}
      }
  
    /* Make sure the champ is better than all the candidates it hasn't yet
!      been compared to.  This may do one more comparison than necessary.  Oh
!      well.  */
  
!   for (challenger = candidates; challenger != champ;
         challenger = challenger->next)
      {
        fate = joust (champ, challenger, 0);
--- 4406,4429 ----
  	      champ = challenger->next;
  	      if (champ == 0)
  		return 0;
+ 	      champ_compared_to_predecessor = 0;
  	    }
  	  else
! 	    {
! 	      champ = challenger;
! 	      champ_compared_to_predecessor = 1;
! 	    }
  
  	  challenger = champ->next;
  	}
      }
  
    /* Make sure the champ is better than all the candidates it hasn't yet
!      been compared to.  */
  
!   for (challenger = candidates; 
!        challenger != champ 
! 	 && !(champ_compared_to_predecessor && challenger->next == champ);
         challenger = challenger->next)
      {
        fate = joust (champ, challenger, 0);

      parent reply	other threads:[~1998-05-25 13:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-06 16:13 Benjamin Redelings I
1998-05-08 19:52 ` Martin von Loewis
1998-05-25 13:43 ` Mark Mitchell [this message]

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=199805251839.LAA21105@mail.earthlink.net \
    --to=mark@markmitchell.com \
    --cc=bredelin@ucsd.edu \
    --cc=egcs@cygnus.com \
    --cc=jason@cygnus.com \
    /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).