Several typos fixed.

Missing or superfluous characters corrected.
Rewording to avoid "problems requires tools".
...
This commit is contained in:
Andreas Scherer 2015-10-18 11:33:03 +02:00
parent 69405d3d15
commit 3e8dc12982

View File

@ -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<B> p = std::make_shared<D>(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<B> p = std::make_shared<D>(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 youre writing an type that maintains an invariant, then all the variables should be private it should be encapsulated.
* *All private*: If youre 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