Mirrors/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2025-12-17 04:44:34 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

Closes #1574

Browse Source 
- Add a cross-reference to C.139 and note that it doesn't matter whether
a function is declared with override or final if the whole class is
already final.
- Fix C.139 to make it clearer that it's about `final` on classes.
This commit is contained in:
hsutter
2020-07-30 11:32:36 -07:00
parent 63e2cd0ecd
commit 945b34d40e
1 changed files with 8 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
CppCoreGuidelines.md
View File

@@ -6821,7 +6821,7 @@ Designing rules for classes in a hierarchy summary:
* [C.136: Use multiple inheritance to represent the union of implementation attributes](#Rh-mi-implementation) * [C.136: Use multiple inheritance to represent the union of implementation attributes](#Rh-mi-implementation)
* [C.137: Use `virtual` bases to avoid overly general base classes](#Rh-vbase) * [C.137: Use `virtual` bases to avoid overly general base classes](#Rh-vbase)
* [C.138: Create an overload set for a derived class and its bases with `using`](#Rh-using) * [C.138: Create an overload set for a derived class and its bases with `using`](#Rh-using)
* [C.139: Use `final` sparingly](#Rh-final) * [C.139: Use `final` on classes sparingly](#Rh-final)
* [C.140: Do not provide different default arguments for a virtual function and an overrider](#Rh-virtual-default-arg) * [C.140: Do not provide different default arguments for a virtual function and an overrider](#Rh-virtual-default-arg)
Accessing objects in a hierarchy rule summary: Accessing objects in a hierarchy rule summary:
@@ -7080,6 +7080,10 @@ We want to eliminate two particular classes of errors:
* **implicit virtual**: the programmer intended the function to be implicitly virtual and it is (but readers of the code can't tell); or the programmer intended the function to be implicitly virtual but it isn't (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be virtual but it is (because it happens to have the same signature as a virtual in the base class) * **implicit virtual**: the programmer intended the function to be implicitly virtual and it is (but readers of the code can't tell); or the programmer intended the function to be implicitly virtual but it isn't (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be virtual but it is (because it happens to have the same signature as a virtual in the base class)
* **implicit override**: the programmer intended the function to be implicitly an overrider and it is (but readers of the code can't tell); or the programmer intended the function to be implicitly an overrider but it isn't (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be an overrider but it is (because it happens to have the same signature as a virtual in the base class -- note this problem arises whether or not the function is explicitly declared virtual, because the programmer may have intended to create either a new virtual function or a new non-virtual function) * **implicit override**: the programmer intended the function to be implicitly an overrider and it is (but readers of the code can't tell); or the programmer intended the function to be implicitly an overrider but it isn't (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be an overrider but it is (because it happens to have the same signature as a virtual in the base class -- note this problem arises whether or not the function is explicitly declared virtual, because the programmer may have intended to create either a new virtual function or a new non-virtual function)
Note: On a class defined as `final`, it doesn't matter whether you put `override` or `final` on an individual virtual function.
Note: Use `final` on functions sparingly. It does not necessarily lead to optimization, and it precludes further overriding.
##### Enforcement ##### Enforcement
* Compare virtual function names in base and derived classes and flag uses of the same name that does not override. * Compare virtual function names in base and derived classes and flag uses of the same name that does not override.
@@ -7650,11 +7654,11 @@ For variadic bases, C++17 introduced a variadic form of the using-declaration,
Diagnose name hiding Diagnose name hiding
### <a name="Rh-final"></a>C.139: Use `final` sparingly ### <a name="Rh-final"></a>C.139: Use `final` on classes sparingly
##### Reason ##### Reason
Capping a hierarchy with `final` is rarely needed for logical reasons and can be damaging to the extensibility of a hierarchy. Capping a hierarchy with `final` classes is rarely needed for logical reasons and can be damaging to the extensibility of a hierarchy.
##### Example, bad ##### Example, bad
@@ -7688,7 +7692,7 @@ However, misuses are (or at least have been) far more common.
##### Enforcement ##### Enforcement
Flag uses of `final`. Flag uses of `final` on classes.
### <a name="Rh-virtual-default-arg"></a>C.140: Do not provide different default arguments for a virtual function and an overrider ### <a name="Rh-virtual-default-arg"></a>C.140: Do not provide different default arguments for a virtual function and an overrider