Bug 74361
| Summary: | check-webkit-style should warn OVERRIDE on destructors | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | jwalden+bwo, kbr |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Ryosuke Niwa
Per http://trac.webkit.org/changeset/102628, it might be a good idea for style bots to warn about OVERRIDE on destructors since they're never right.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Jeff Walden (remove +bwo to email)
In the not-actually-final draft C++11 I have, it appears to be okay to add override to any virtual member function (that overrides), including virtual destructors. Is MSVC requiring something above and beyond (and in violation of) the spec, such that as a purely practical matter "override" shouldn't be used this way? Just curious.
Ryosuke Niwa
(In reply to comment #1)
> In the not-actually-final draft C++11 I have, it appears to be okay to add override to any virtual member function (that overrides), including virtual destructors. Is MSVC requiring something above and beyond (and in violation of) the spec, such that as a purely practical matter "override" shouldn't be used this way? Just curious.
Why do we ever want to override destructors? What does that mean semantically mean?
Jeff Walden (remove +bwo to email)
In C++11 it's an override like any other. Destructors having no arguments, and special syntax, makes it rather harder to typo a destructor to not override the inherited destructor, such that "override" provides value in checking for a proper override. But it seems semantically understandable to me.
I'm just wondering if I want to tell people not to do this in Mozilla because MSVC won't let you do it, MSVC warns when you do it, or because there's not much point to it.
Ryosuke Niwa
(In reply to comment #3)
> In C++11 it's an override like any other. Destructors having no arguments, and special syntax, makes it rather harder to typo a destructor to not override the inherited destructor, such that "override" provides value in checking for a proper override. But it seems semantically understandable to me.
But we can never "override" destructors in the sense that destructors of superclasses are always called.
> I'm just wondering if I want to tell people not to do this in Mozilla because MSVC won't let you do it, MSVC warns when you do it, or because there's not much point to it.
IMO, it's rather confusing to have "override" keyword on a destructor due to the above semantics (unless adding override keyword changes the behavior of virtual destructors).