public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "zsojka at seznam dot cz" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/46043] New: attribute to mark virtual methods that can't be further overriden so they can be devirtualized Date: Sat, 16 Oct 2010 12:04:00 -0000 [thread overview] Message-ID: <bug-46043-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46043 Summary: attribute to mark virtual methods that can't be further overriden so they can be devirtualized Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: zsojka@seznam.cz In some scenarios, there is one abstract class declaring virtual methods with several derived classes, all of them overriding those methods. (at least in OpenTTD that happens often) The important point is that there are no further derived classes from those. For example: struct A { virtual void f1() = 0; virtual void f2() = 0; virtual void f3() { ... this->f1(); this->f2(); ... } }; struct B : A { virtual void f1(); virtual void f2() { ... this->f1(); ... } }; struct C : A { virtual void f1(); virtual void f2(); virtual void f3() { ... this->f1(); this->f2(); ... } }; struct D : A { virtual void f1(); virtual void f2(); }; If there was an information that there are no classes derived from B,C,D, it would allow many devirtualizations. One idea I could come with would be omitting the "virtual" keyword causing the method to lose its "virtual" status. But that would break a lot of existing code. Second idea is using an attribute for that. While searching for this issue I found java uses "final" keyword for this purpose (or at least it seems to me so), so I will use attribute "final" in the following example: struct A { virtual void f1(); virtual void f2(); virtual void f3(); }; /* f1() can't be further overriden */ struct B : A { virtual void f1() __attribute__((final)); }; /* no virtual method can further be overriden */ struct C : A { virtual void f3(); } __attribute__((final)); struct D : C { virtual void f4(); }; struct E : D { } __attribute__((final)); void foo(struct C *c, struct D *d, struct E *e) { c->f1(); /* c->B::f1() */ c->f2(); /* c->A::f2() */ c->f3(); /* c->C::f3() */ d->f1(); /* d->B::f1() */ d->f4(); /* not known at compile-time */ e->f1(); /* e->B::f1() */ e->f4(); /* e->D::f4() */ } /* The following results in compile errors */ struct F : D { virtual void f1(); /* error */ virtual void f2(); /* error */ virtual void f3(); /* error */ virtual void f4(); }; I searched the bugzilla for this issue and found none open. Given this idea is quite simple and the gain can be high, there might be something I overlooked.
next reply other threads:[~2010-10-16 12:04 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-10-16 12:04 zsojka at seznam dot cz [this message] 2010-10-16 14:01 ` [Bug c++/46043] " redi at gcc dot gnu.org 2010-10-16 15:46 ` redi at gcc dot gnu.org 2010-10-16 15:50 ` zsojka at seznam dot cz 2010-10-27 22:12 ` pinskia at gcc dot gnu.org 2010-10-28 8:50 ` redi at gcc dot gnu.org 2011-07-07 22:02 ` jason at gcc dot gnu.org 2011-07-17 11:46 ` paolo.carlini at oracle dot com 2011-07-17 13:12 ` jason 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=bug-46043-4@http.gcc.gnu.org/bugzilla/ \ --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: linkBe 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).