This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/15269] __attribute__((deprecated)) broken with inline, ignored with pure virtual, misreported after definition
- From: "eddy at opera dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 May 2004 19:08:13 -0000
- Subject: [Bug c++/15269] __attribute__((deprecated)) broken with inline, ignored with pure virtual, misreported after definition
- References: <20040503180849.15269.eddy@opera.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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