public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/10496: erroneus suggestion in diagnostic and possible bug
@ 2003-04-26  6:56 Gabriel Dos Reis
  0 siblings, 0 replies; 4+ messages in thread
From: Gabriel Dos Reis @ 2003-04-26  6:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Pal Benko <benko@sztaki.hu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/10496: erroneus suggestion in diagnostic and possible bug
Date: 26 Apr 2003 08:47:20 +0200

 Pal Benko <benko@sztaki.hu> writes:
 
 | >From benko Fri Apr 25 15: 49 MES 2003
 | References: <20030425130751.2623.qmail@sources.redhat.com>
 |  <m3ist2hg47.fsf@uniton.integrable-solutions.net>
 | 
 | > | (&a::f is accepted.)
 | > 
 | > But isn't what you wrote in your testcase?  Sometime  is odd about it.
 | 
 | Sorry, I muddled up something.  I wrote &f, the compiler told me to
 | write &const a::f, 
 
 Yes, that is an error from the compiler side.  I'll reword the synopsys.
 
 | I'm sort of interested in why &a::f is better than &f - I'm in a
 | member function of a, aren't I?
 
 You're in the scope of a, but that is irrelevant because the C++
 definition says that the only way to form a pointer to member is to
 say &class-name :: member.
 
 -- Gaby


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: c++/10496: erroneus suggestion in diagnostic and possible bug
@ 2003-04-25 13:56 Pal Benko
  0 siblings, 0 replies; 4+ messages in thread
From: Pal Benko @ 2003-04-25 13:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Pal Benko <benko@sztaki.hu>
To: gdr@integrable-solutions.net
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/10496: erroneus suggestion in diagnostic and possible bug
Date: Fri, 25 Apr 2003 15:49:26 +0200

 > | (&a::f is accepted.)
 > 
 > But isn't what you wrote in your testcase?  Sometime  is odd about it.
 
 Sorry, I muddled up something.  I wrote &f, the compiler told me to
 write &const a::f, and I figured out that &a::f is accepted.
 
 I'm sort of interested in why &a::f is better than &f - I'm in a
 member function of a, aren't I?
 
 Pal Benko
 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: c++/10496: erroneus suggestion in diagnostic and possible bug
@ 2003-04-25 13:26 Gabriel Dos Reis
  0 siblings, 0 replies; 4+ messages in thread
From: Gabriel Dos Reis @ 2003-04-25 13:26 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: benko@sztaki.hu
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/10496: erroneus suggestion in diagnostic and possible bug
Date: 25 Apr 2003 15:16:24 +0200

 benko@sztaki.hu writes:
 
 [...]
 
 | arta:~/c/proba$ cat ptr2mem.cc
 | struct a
 | {
 |   int f() const;
 | };
 | 
 | 
 | int
 | a::f() const
 | {
 |   int (a::* b)() const = &a::f;
 | }
 | arta:~/c/proba$ g++3 -v
 | Reading specs from /gml/shared/gcc-3.2.3/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/specs
 | Configured with: ../gcc-3.2.3/configure --prefix=/gml/shared/gcc-3.2.3
 | Thread model: posix
 | gcc version 3.2.3
 | arta:~/c/proba$ g++3 ptr2mem.cc
 | ptr2mem.cc: In member function `int a::f() const':
 | ptr2mem.cc:10: ISO C++ forbids taking the address of an unqualified non-static 
 |    member function to form a pointer to member function.  Say `&const a::f'
 
 Odd.
 
 | I think &f should be enough, but &const a::f
 
 No, "&f" is no good and "&const a::f" is weird and plain dead wrong.  
 "&a::f" is good.  
 
 | (as suggested by the diagnostics) is refused by g++
 | (I think rightly so).
 | 
 | (&a::f is accepted.)
 
 But isn't what you wrote in your testcase?  Sometime  is odd about it.
 
 -- Gaby


^ permalink raw reply	[flat|nested] 4+ messages in thread

* c++/10496: erroneus suggestion in diagnostic and possible bug
@ 2003-04-25 13:16 benko
  0 siblings, 0 replies; 4+ messages in thread
From: benko @ 2003-04-25 13:16 UTC (permalink / raw)
  To: gcc-gnats


>Number:         10496
>Category:       c++
>Synopsis:       erroneus suggestion in diagnostic and possible bug
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 25 13:16:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     benko@sztaki.hu
>Release:        3.2.3
>Organization:
>Environment:
Linux arta 2.4.18 #2 Thu Feb 28 19:27:45 CET 2002 i686 unknown
>Description:
Given the following program:

arta:~/c/proba$ cat ptr2mem.cc
struct a
{
  int f() const;
};


int
a::f() const
{
  int (a::* b)() const = &a::f;
}
arta:~/c/proba$ g++3 -v
Reading specs from /gml/shared/gcc-3.2.3/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/specs
Configured with: ../gcc-3.2.3/configure --prefix=/gml/shared/gcc-3.2.3
Thread model: posix
gcc version 3.2.3
arta:~/c/proba$ g++3 ptr2mem.cc
ptr2mem.cc: In member function `int a::f() const':
ptr2mem.cc:10: ISO C++ forbids taking the address of an unqualified non-static 
   member function to form a pointer to member function.  Say `&const a::f'
zsh: exit 1     g++3 ptr2mem.cc
arta:~/c/proba$

I think &f should be enough, but &const a::f
(as suggested by the diagnostics) is refused by g++
(I think rightly so).

(&a::f is accepted.)
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-04-26  6:56 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-26  6:56 c++/10496: erroneus suggestion in diagnostic and possible bug Gabriel Dos Reis
  -- strict thread matches above, loose matches on Subject: below --
2003-04-25 13:56 Pal Benko
2003-04-25 13:26 Gabriel Dos Reis
2003-04-25 13:16 benko

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).