From 3e8dc12982340ad85fae7882f0e426356b116273 Mon Sep 17 00:00:00 2001 From: Andreas Scherer Date: Sun, 18 Oct 2015 11:33:03 +0200 Subject: [PATCH] Several typos fixed. Missing or superfluous characters corrected. Rewording to avoid "problems requires tools". ... --- CppCoreGuidelines.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 0605f0d..c47ccfc 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -5251,7 +5251,7 @@ A class with a virtual function is usually (and in general) used via a pointer t ##### Note -There are people who don't follow this rule because they plan to use a class only through a `shared_ptr`: `std::shared_ptr p = std::make_shared(args);` Here, the shared pointer will take care of deletion, so no leak will occur from and inappropriate `delete` of the base. People who do this consistently can get a false positive, but the rule is important -- what if one was allocated using `make_unique`? It's not safe unless the author of `B` ensures that it can never be misused, such as by making all constructors private and providing a factory functions to enforce the allocation with `make_shared`. +There are people who don't follow this rule because they plan to use a class only through a `shared_ptr`: `std::shared_ptr p = std::make_shared(args);` Here, the shared pointer will take care of deletion, so no leak will occur from an inappropriate `delete` of the base. People who do this consistently can get a false positive, but the rule is important -- what if one was allocated using `make_unique`? It's not safe unless the author of `B` ensures that it can never be misused, such as by making all constructors private and providing a factory function to enforce the allocation with `make_shared`. ##### Enforcement @@ -5289,7 +5289,7 @@ Readability. Detection of mistakes. Explicit `override` allows the compiler to c ##### Reason - ??? Herb: I've become a non-fan of implementation inheritance -- seems most often an antipattern. Are there reasonable examples of it? + ??? Herb: I've become a non-fan of implementation inheritance -- seems most often an anti-pattern. Are there reasonable examples of it? ##### Example @@ -5421,7 +5421,7 @@ This leaves us with three alternatives: * *All public*: If you're writing an aggregate bundle-of-variables without an invariant across those variables, then all the variables should be public. [Declare such classes `struct` rather than `class`](#Rc-struct) * *All protected*: [Avoid `protected` data](#Rh-protected). -* *All private*: If you’re writing an type that maintains an invariant, then all the variables should be private – it should be encapsulated. +* *All private*: If you’re writing a type that maintains an invariant, then all the variables should be private – it should be encapsulated. This is the vast majority of classes. ##### Example @@ -5546,7 +5546,7 @@ Capping an individual virtual function with `final` is error-prone as that `fina use(new Better_interface{}); -The problem is easy to see in a small example, but in a large hierarchy with many virtual functions, reliable spotting such problems require tools. +The problem is easy to see in a small example, but in a large hierarchy with many virtual functions, tools are required for reliably spotting such problems. Consistent use of `override` would catch this. ##### Note @@ -5695,7 +5695,7 @@ and that your use of `dynamic_cast` is really performance critical. We are of the opinion that current implementations of `dynamic_cast` are unnecessarily slow. For example, under suitable conditions, it is possible to perform a `dynamic_cast` in [fast constant time](http://www.stroustrup.com/fast_dynamic_casting.pdf). -However, compatibility makes changes difficult even if all agree that an effort to optimize is worth while. +However, compatibility makes changes difficult even if all agree that an effort to optimize is worthwhile. ##### Enforcement