[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[thomas dot mcguire at gmx dot net]

------- Comment #7 from thomas dot mcguire at gmx dot net  2008-08-21 18:43 -------
Just want to add my support for this feature.

I had quite some bugs which I would have discovered earlier if this warning
here was implemented.
In particular, in KDE4/Qt4, lots of virtual functions were removed or changed,
and the code using was never adjusted properly, and now just silently fails.


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[pluto at agmk dot net]

------- Comment #8 from pluto at agmk dot net  2008-08-21 19:04 -------
why just not to use -Woverloaded-virtual?

$ g++ reimpl.cpp -Wall -c -Woverloaded-virtual
reimpl.cpp:1: warning: 'virtual void A::foo() const' was hidden
reimpl.cpp:2: warning:   by 'void B::foo()'


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[thomas dot mcguire at gmx dot net]

------- Comment #9 from thomas dot mcguire at gmx dot net  2008-08-21 19:15 -------
> why just not to use -Woverloaded-virtual?

Because that does not help if the virtual function was completely removed from
the base class. We actually do use -Woverloaded-virtual, btw.


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[Woebbeking at web dot de]

------- Comment #10 from Woebbeking at web dot de  2008-11-30 15:46 -------
And if you've many overloads of a virtual function and override only one you
also get a warning. And in some projects this happens very often :-(

So I also support this suggestion!


-- 

Woebbeking at web dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Woebbeking at web dot de


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2008-12-27 22:02 -------
*** Bug 36796 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slime at apple dot com


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[shcherbakov at daad-alumni dot de]

------- Comment #12 from shcherbakov at daad-alumni dot de  2010-01-05 16:27 -------
I would also appreciate if an attribute like this is supported by gcc due to
several reasons:
  1. Developers that want to ensure that a virtual method actually overrides
another virtual method of a base class will have means of doing it
automatically (via this __attribute__). Basically, instead of checking every
method signature manually when an updated version of some C++ framework was
released, all checks can be done automatically.
  2. Provided that if this attribute is not used, the compiler behavior will
remain unchanged, nobody will get hurt. Those who don't use the attribute
(and/or don't know about it) won't have any difference, while those who do -
will have better user experience (e.g. if a noreturn function is not marked as
a noreturn, it is maybe a missed optimization chance, but not a problem to
those who don't know about "noreturn").
  3. Not supporting an extension until C++ committee states it is a strange
argument, as already GCC supports many time-saving functionality with backward
compatibility (e.g. printf() argument checking or __attribute__((noreturn)))
and nobody complains that they are not approved by C++ committee. As soon as
such extensions are not incompatible with "pure C++", they do not mean any
problems. 
  4. -Woverloaded-virtual won't help if a class is designed to contain several
overloads for a virtual method.
  5. Implementing support such attribute should not be a big problem (as the
VTABLE generation code that checks whether the method overrides another method
should just check one attribute and produce one error if it is defined).

To Andrew Pinski: If the proposed feature is still found to be unreasonable, I
am ready to discuss it and provide additional arguments.


-- 

shcherbakov at daad-alumni dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[jwakely dot gcc at gmail dot com]

------- Comment #13 from jwakely dot gcc at gmail dot com  2010-01-06 11:58 -------
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm which is
part of the current C++ draft

Related to Bug 31397 and Bug 36848 - we don't need three open bugs requesting
similar features.  I've suggested ((override)) ((base_check)) and ((hiding))
should be implemented using __attribute__ until C++1x attributes are supported


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-21 16:00:11 UTC ---
G++ 4.7 supports C++0x explicit override control, so the example can be changed
to:

struct A { virtual void foo() const; };
struct B : public A { void foo() override; };

And you get:

final.cc:2:28: error: 'void B::foo()' marked override, but does not override

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-10-11 12:54 -------
I concur with Giovanni: this is a case very much like the format 
checking for printf and attribute sentinel. If you simply remove 
the attribute statement, then the generated code is exactly the 
same in all cases, the attribute is there only to enable the compiler 
to emit more warnings. 
 
W. 

-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-10-11 09:28 -------
(In reply to comment #4)

> I disagree with the notion that it is just a diagnostic related issue;
> because it comes with a semantics part.  Let's not not disguise a
> language extension under the name of diagnostic improvement.  
> It helps nobody. 

I am not trying to, really.

In my view, the compilation unit will produce exactly the same object file, 
whether attribute(reimpl) is implemented or not, used or not. The only 
difference is that with attribute(reimpl) we might emit a warning iff the 
method does not override another virtual method in the base class.

Why do you think there is a semantics part? Maybe I do not get it.

-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[gdr at cs dot tamu dot edu]

------- Additional Comments From gdr at cs dot tamu dot edu  2004-10-10 22:46 -------
Subject: Re:  add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| As far as I can tell, this is just a hint for the compiler to
| generate better diagnostic. Pretty much like attribute(sentinel) for
| instance: we just give the compiler more information, we are not
| modifying the semantic of a program. 
| 
| I'm actually in favor of this PR so I will confirm this. This is not an 
| extension as in we are modifying the language semantic, adding
| strange features or whatnot.

I disagree with the notion that it is just a diagnostic related issue;
because it comes with a semantics part.  Let's not not disguise a
language extension under the name of diagnostic improvement.  
It helps nobody. 

-- Gaby


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-10-10 22:41 -------
As far as I can tell, this is just a hint for the compiler to generate better 
diagnostic. Pretty much like attribute(sentinel) for instance: we just give the 
compiler more information, we are not modifying the semantic of a program.

I'm actually in favor of this PR so I will confirm this. This is not an 
extension as in we are modifying the language semantic, adding strange features 
or whatnot.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-10-10 22:41:32
               date|                            |


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[gdr at cs dot tamu dot edu]

------- Additional Comments From gdr at cs dot tamu dot edu  2004-10-10 16:14 -------
Subject: Re:  add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I don't think we want an extension like this unless it is drafted to
| the C++ committee. 

For the record, that usually surfaces as "override" keyword in
recurrent discussions.  The debates date back to the earlier days when
virtual was introduced in C++.  Nothing has ever happened.

I don't think I'm in favor of this PR.

-- Gaby


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-10 16:06 -------
I don't think we want an extension like this unless it is drafted to the C++ committee.

-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3


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