public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: c++/7016
Date: Thu, 23 Jan 2003 15:46:00 -0000	[thread overview]
Message-ID: <20030123154601.9744.qmail@sources.redhat.com> (raw)

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/7016
Date: Thu, 23 Jan 2003 09:41:57 -0600 (CST)

 > The original issue was not (only) with overloading, but also with this
 > operator not being available for the basic scalar types (while <? and >?
 > are). Thanks, Jan
 
 I double checked, and found that you can indeed overload >? and <? with 
 the new parser. However, I cannot find any mention of operators <?= and 
 >?= at all, so am I right that what you want is to extend the gcc 
 extension
   >? and <?
 to also recognize
   >?= and <?=
 and be able to overload these? Frankly, for standard types, these 
 operators do not make much sense, so I guess that's the reason why they do 
 not exist at all. 
 
 That being said: the reason given in the manual for their existence must 
 predate templates -- the example uses a macro
   #define MAX(a,b) ((a) > (b) ? (a) : (b))
 and whines about the fact that if a or b have side effects, then this may 
 not be what you want. Today, with templates, there's a much more elegant 
 solution, and if you ask me then let's deprecate the feature.
 
 W.
 
 
 > >>> <bangerth@dealii.org> 23.01.03 04:11:18 >>>
 > Synopsis: missing definitions for <?= and >?=
 > 
 > State-Changed-From-To: analyzed->closed
 > State-Changed-By: bangerth
 > State-Changed-When: Thu Jan 23 03:11:18 2003
 > State-Changed-Why:
 >     This is probably a corner case whether I should close the
 >     report: this has never worked (used to ICE)
 >     ---------------------------------
 >     class C {};
 >     C operator <?= (C) { return C(); }
 >     --------------------------------------
 >     I don't think it was ever documented that one should be
 >     able to overload this operator (a gcc extension anyway).
 >     Now we at least get a reasonable error:
 >     g/a> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc
 >     x.cc:2: error: expected identifier
 >     x.cc:2: error: expected type-name
 >     x.cc:2: error: expected `,' or `;'
 >     
 >     So the fact that the new parser rejects the code is ok, and
 >     is not removing a documented extension.
 >     
 >     W.
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7016
 > 
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 
 
 


             reply	other threads:[~2003-01-23 15:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-23 15:46 Wolfgang Bangerth [this message]
2003-01-23 15:46 c++/7016 Wolfgang Bangerth
2003-01-23 15:46 c++/7016 Wolfgang Bangerth
2003-01-23 16:46 c++/7016 Wolfgang Bangerth
2003-01-23 17:06 c++/7016 Wolfgang Bangerth

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=20030123154601.9744.qmail@sources.redhat.com \
    --to=bangerth@ticam.utexas.edu \
    --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).