* Tighten up CP.1
* balanced verb usage in first sentence
* changed third sentence to "libraries not using threads", as I
believe this was the original author's intended meaning.
* clarified "this" in fourth sentence
* cut wordiness of "thanks to the magic of cut-and-paste", as it
added no value
* changed "Example" heading to "Example, bad"
* added "bad:" comment above statics in the example
* added an explanatory sentence immediately after the example
* changed "works perfectly in a single-threaded" after example to
"works as intended in a single threaded". Also balanced the
structure of the two comma separated phrases inside this sentence.
* strengthened parenthetical explanation in second bullet of "could
be made safe" section
* Correct grammar mistake pointed out by @cubbimew
* Remove specific cache details in CP.1 per @hsutter's request
* Added bad and goof example to NR.5 in CppCoreGuidelines.md
Added bad and good example to NR.5 Don’t: Don’t do substantive work in a constructor; instead use two-phase initialization.
I think it could be suitable.
* adjusted coding style
* removed extra space
* removed one more whitespace
* removed spaces before note to make it a blank line
* made Cleanup method from bad example return void
* some changes after review comments
- removed try catch
- removed defaulted dtor
- changed int to size_t, removed check for even.
- Expects() for invariant check
- typo
* spell check adjustment
* moved comment up for met the line length
* changed variablename in good example
... they were named same after removed the try catch scope
* changed afer comments
- changed check_size() function to a static member function
- fixed comment mentioning the default contract violation behavior.
* C.129 Fix typos and conjugation
I noticed some grammatical errors in this section and fixed them to match my interpretation of the author's intention.
* One more fix
Pluralization
* Use `memoizes` instead of `mnemonizes` in the context of caching
While apparently, 'mnemonizes' is a word, I don't think it's the best choice here.
* Update isocpp.dic
The code fails to set the type when a number value is assigned to a (formerly) string value. As a result, later access to the value or destruction of the object cause undefined behaviour (access to arbitrary memory address and/or heap corruption). The string field of the union is accessed, but its the number what is there…
It's also wrong in the book!
The fact that this bug has survived so long pretty much proves the point that code with unions is hard to get right ;-)
Oh, by the way, in order to test this, I had to add a constructor. Though, I'm not including it in the change. I suppose this just stuff we take for granted in the "// …" comment.
