@@ -225,7 +225,7 @@ They are meant to inhibit perfectly valid C++ code that correlates with errors,
225
225
The rules are not perfect.
226
226
A rule can do harm by prohibiting something that is useful in a given situation.
227
227
A rule can do harm by failing to prohibit something that enables a serious error in a given situation.
228
- A rule can do a lot of harm by being vague, ambiguous, unenforcable , or by enabling every solution to a problem.
228
+ A rule can do a lot of harm by being vague, ambiguous, unenforceable , or by enabling every solution to a problem.
229
229
It is impossible to completely meet the "do no harm" criteria.
230
230
Instead, our aim is the less ambitious: "Do the most good for most programmers";
231
231
if you cannot live with a rule, object to it, ignore it, but don't water it down until it becomes meaningless.
@@ -11292,7 +11292,7 @@ these `thread`s can be seen as just a function object called from `some_fct`.
11292
11292
##### Enforcement
11293
11293
11294
11294
In general, it is undecidable whether a `detach()` is executed for a `thread`, but simple common cases are easily detected.
11295
- If we cannot prove that a `thread` does not `detatch ()`, we must assume that it does and that it outlives the scope in which it was constructed;
11295
+ If we cannot prove that a `thread` does not `detach ()`, we must assume that it does and that it outlives the scope in which it was constructed;
11296
11296
After that, the usual lifetime and ownership (for global objects) enforcement applies.
11297
11297
11298
11298
@@ -11665,7 +11665,7 @@ We could rewrite this to
11665
11665
do0(); // preparation: does not need lock
11666
11666
my_lock.lock();
11667
11667
do1(); // transaction: needs locking
11668
- my_lock.unluck ();
11668
+ my_lock.unlock ();
11669
11669
do2(); // cleanup: does not need locking
11670
11670
}
11671
11671
0 commit comments