[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #3 from Thomas dot Lange at sun dot com 2009-07-08 10:23 --- (In reply to comment #2) > why don't you add a 'virtual' > to your destructor and int f(int) functions, because they are implicitly > virtual anyway'. That is exactly the point this is about! I want a way so the compiler enforces to add 'virtual' to ~B and B::f, and thus help to write better understandable code. This is in order for large derived trees or a big source code. It is for the one looking at the declaration (and not anymore or not at all familiar with the code!) to not miss that those functions are virtual. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #4 from Thomas dot Lange at sun dot com 2009-07-08 10:30 --- Side note: Of course having such an option is much more useful where the declaration of class A and B are in different header files and probably even in different modules. (For example: such cases are often found in the OpenOffice.org source code... ^_-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #6 from Thomas dot Lange at sun dot com 2009-07-13 11:56 --- (In reply to comment #5) No. I do mean overloaded! It might be nice to have a warning for overloading virtual functions of base classes as well. But my point is that the compiler should help to enforce that every virtual function has the 'virtual' keyword set in its declaration. Thus effectively removing those implicit virtual functions that are allowed in C++. The goal is: Either a function should be explicitly declared virtual in its declaration or not be virtual at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #8 from Thomas dot Lange at sun dot com 2009-07-13 12:02 --- (In reply to comment #6) Ooops... Sorry! I just was told that I confused those two terms. >_< (That might happen to non-native speakers) My apologies! Yes you are correct. It is about overwriting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #9 from Thomas dot Lange at sun dot com 2009-07-13 12:07 --- (In reply to comment #6) I'm not concerned about that case. Thank you for your time! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] New: Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
When trying to build the OOo code warning-free we turned all useful warnings on and get rid of them. But there is one warning that would be really useful missing. It is not required for code correctness or safety at all, but it would be most useful to have better understandable code. What I/we at OOo would like to have is a warning when a when a function in a derived class is overloaded without specifing 'virtual'. This would allow to identify all the cases where this is missing and in the end it would be clear just be looking at the specific declaration of a class which functions are virtual and which not. Right now in our sometimes very old code it is quite troublesome to always go up in the class hierarchy in order to check this. Example: class A { A(); virtual ~A(); virtual int f( int x ); }; class B : public A { B( int y ); ~B(); int f( int x ); }; It would be nice if there would be warnings for ~B and f not using the 'virtual' keyword. Together with the switch to treat warnings as errors this would help to produce better understandable code. -- Summary: Useful compiler warning missing (virtual functions in derived classes used without 'virtual') Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Lange at sun dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397