public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "eddy at opera dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/15269] __attribute__((deprecated)) broken with inline, ignored with pure virtual, misreported after definition
Date: Mon, 03 May 2004 19:08:00 -0000	[thread overview]
Message-ID: <20040503190813.14076.qmail@sources.redhat.com> (raw)
In-Reply-To: <20040503180849.15269.eddy@opera.com>


------- Additional Comments From eddy at opera dot com  2004-05-03 19:08 -------
Subject: Re:  __attribute__((deprecated)) broken with inline, ignored with pure virtual, misreported after definition

Nice to see the inline problem is fixed already :^)

Unless it's also been fixed in the interval,
problem number three is this:

-----------
struct B {
    void foo() __attribute__((deprecated)); // declaration
    // documentation of why it's deprecated, how to dispense with it
}
void B::foo() { return; } // definition
void demo(void) { ((B*)0)->foo(); } // gets warning
-----------

the compiler's warning says foo was declared at line 5 when it was
actually declared at line 2.  If (as will be true in any real example)
the declaration is in a header file and the definition is in a
separate source file, whoever comes along to fix the warning is going
to be directed to the definition, which doesn't have the documentation
of why the method is decremented and how to do without it.

This will be particularly monstrous if in fact the attribute is on a
distant base class of B (I can't test this because of problem number
one): the implementation of (some class in the same compilation unit
as) B calls the foo of a B object after B has defined foo; the warning
*really* needs to reference the far off header file which defines the
base class ... being told about B's implementation of foo will be
little use !

	Eddy.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15269


  parent reply	other threads:[~2004-05-03 19:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-03 18:08 [Bug c++/15269] New: " gcc-bugzilla at gcc dot gnu dot org
2004-05-03 18:39 ` [Bug c++/15269] " bangerth at dealii dot org
2004-05-03 19:08 ` eddy at opera dot com [this message]
2004-05-03 19:17 ` bangerth at dealii dot org
2004-05-03 19:20 ` pinskia at gcc dot gnu dot org
     [not found] <bug-15269-8457@http.gcc.gnu.org/bugzilla/>
2007-09-23  4:33 ` jason at gcc dot gnu dot org
2007-09-23  4:37 ` jason at gcc dot gnu dot org
2007-09-23  4:40 ` jason at gcc dot gnu dot org
2007-09-25 15:54 ` eddy at opera dot com
     [not found] <bug-15269-4@http.gcc.gnu.org/bugzilla/>
2021-08-11 20:25 ` pinskia at gcc dot gnu.org

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=20040503190813.14076.qmail@sources.redhat.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).