fcb2960793
This PR affirms that all virtual functions, *including destructors*, should be declared exactly one of `virtual`, `override`, or `final`, and takesa pass through the document to make the examples and guidance consistent with that. Of course a virtual destructor is a virtual function: It behaves polymorphically, and it has a vtable entry that can be overwritten == overridden in a derived class exactly the same as any other derived virtual override. See also [class.virtual]/7: "Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual; see [class.dtor] and [class.free]." However, the following exception text currently appears in C.128: > If a base class destructor is declared `virtual`, one should avoid declaring derived class destructors `virtual` or `override`. Some code base and tools might insist on `override` for destructors, but that is not the recommendation of these guidelines. ... but this exception is (a) not well-founded, and (b) inconsistent with the Guidelines' practice in other examples and with the rationale a few lines earlier for C.128 itself. Re (a): - The exception is overly broad: The rationale given for this exception is entirely against marking destructors `override` (not `virtual`). So clearly the exception to write neither keyword is too broad: At most, the exception should be to write `virtual` rather than `override`. - Explicit `virtual` is primarily for class users, not class authors: The arguments given in #721 favoring this exception are from the viewpoint of the implementation of the function (even then, the arguments are debatable and debated). But `virtual`, `override`, and `final` are primarily for the far larger audience of *class users and call sites* of the function, for whom of course we should document each declared function that is polymorphic, *especially* the destructor -- this tells calling code whether the function is safe to call through a (smart or built-in) pointer or reference to base, which will nearly always be the case for such types. We should not make the reader of the code go way to look in the base classes to figure out whether a function declared in this class is virtual or not -- the reason this Item exists is primarily to avoid that implicit virtual antipattern via convention and automated enforcement. For class users, all virtual functions including destructors are equally polymorphic. Re (b): The Guidelines already don't follow this. For instance, two Items later (in C.130) we have this example that correctly uses `override`: ~~~ virtual ~D() override; ~~~ ... though per C.128 it should not also specify `virtual` (also fixed in this PR). Finally, the exception also contradicts the rationale given earlier in the same Item. |
||
|---|---|---|
| docs | ||
| scripts | ||
| talks | ||
| .gitignore | ||
| .travis.yml | ||
| C++ Core Guidelines weekly telecon.eml | ||
| call-in number.eml | ||
| CONTRIBUTING.md | ||
| cpp_core_guidelines_logo_text.png | ||
| CppCoreGuidelines.md | ||
| dump.cpp | ||
| LICENSE | ||
| param-passing-advanced.png | ||
| param-passing-normal.png | ||
| README.md | ||
"Within C++ is a smaller, simpler, safer language struggling to get out." -- Bjarne Stroustrup
The C++ Core Guidelines are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many person-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but they can be freely copied and modified to meet your organization's needs.
Getting started
The guidelines themselves are found at CppCoreGuidelines. The document is in GH-flavored MarkDown. It is intentionally kept simple, mostly in ASCII, to allow automatic post-processing such as language translation and reformatting. The editors maintain one version formatted for browsing. Note that it is manually integrated and can be slightly older than the version in the master branch.
The Guidelines are a constantly evolving document without a strict "release" cadence. Bjarne Stroustrup periodically reviews the document and increments the version number in the introduction. Checkins that increment the version number are tagged in git.
Many of the guidelines make use of the header-only Guidelines Support Library. One implementation is available at GSL: Guidelines Support Library.
Background and scope
The aim of the guidelines is to help people to use modern C++ effectively. By "modern C++" we mean C++11, C++14, and C++17. In other words, what would you like your code to look like in 5 years' time, given that you can start now? In 10 years' time?
The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. Such rules affect application architecture and library design. Following the rules will lead to code that is statically type-safe, has no resource leaks, and catches many more programming logic errors than is common in code today. And it will run fast -- you can afford to do things right.
We are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is out of bounds.
Our initial set of rules emphasizes safety (of various forms) and simplicity. They may very well be too strict. We expect to have to introduce more exceptions to better accommodate real-world needs. We also need more rules.
You will find some of the rules contrary to your expectations or even contrary to your experience. If we haven't suggested that you change your coding style in any way, we have failed! Please try to verify or disprove rules! In particular, we'd really like to have some of our rules backed up with measurements or better examples.
You will find some of the rules obvious or even trivial. Please remember that one purpose of a guideline is to help someone who is less experienced or coming from a different background or language to get up to speed.
The rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule. We do not expect you to memorize all the rules before trying to write code.
The rules are meant for gradual introduction into a code base. We plan to build tools for that and hope others will too.
Contributions and LICENSE
Comments and suggestions for improvements are most welcome. We plan to modify and extend this document as our understanding improves and the language and the set of available libraries improve. More details are found at CONTRIBUTING and LICENSE.
Thanks to DigitalOcean for hosting the Standard C++ Foundation website.