This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/53206] overloaded virtual non const warning
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 03 May 2012 13:28:50 +0000
- Subject: [Bug c++/53206] overloaded virtual non const warning
- Auto-submitted: auto-generated
- References: <bug-53206-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53206
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-05-03 13:28:50 UTC ---
This is slightly contrived:
namespace library
{
struct Interface {
virtual void handle(int) = 0;
};
struct Implementation : Interface {
void handle(int i) { __builtin_printf("handled %d\n", i); }
};
}
struct Application : private library::Implementation
{
Application(int i) : id(i) { }
void handle() { Implementation::handle(id); }
int id;
};
int main()
{
Application a(1);
a.handle();
}
I don't care that Application::handle() hides Implementation::handle(int), no
user of Application needs to know about the private base class and can never
call the virtual function directly anyway.
To suppress the warning it's necessary to rename one of the functions (which
might involve changing a third-party library or breaking your clas' API) or to
add "using Implementation::handle" but that using decl *must* be private or it
allows users of Application to invoke the virtual function that is meant to be
inaccessible.
I don't object to putting it in -Wall, I'm just pointing out there are cases
where the warning is unhelpful. I wonder if suppressing it when the hidden
virtual function is inaccessible would make snse ... I haven't thought about
all the consequences of doing that (and it still wouldn't remove all unhelpful
cases of the warning, I just can't think of all the times I've got the warning
and decided it should be ignored.)