When a reference in the Bibliography is available online, it would seem to be nice to have a link. In this example, the original article was published in C/C++ User's Journal, with the content later ported to the DDJ web site. The DDJ site is no longer reliable, but a good copy exists in archive.org, and I've linked to it here.
* make the sample in Sd-factory compileable (closes#1488)
- make the sample in Sd-factory compileable
- fixed wrong capitalization: create/Create -> create
- `make_shared` cannot access protected constructors, so made them public. To still have access protection introduced a protected `class Token` in each class. That token can only be created by the class itself (and derived classes) and needs to be passed to the constructor.
- changed order: `public` first, then `protected`
- same sample for C.50 and Sd-factory
- removed spurious "see Item 49.1" as it is unclear what this means
* line length
* tabs -> spaces
* spelling
* input from cubbimew
- added back in Item 49.1
- added link for items as suggested ("in [SuttAlex05](#SuttAlex05)")
* changed link to Item 49.1 to link to C.82
This PR affirms that all virtual functions, *including destructors*,
should be declared exactly one of `virtual`, `override`, or `final`, and
takesa pass through the document to make the examples and guidance
consistent with that.
Of course a virtual destructor is a virtual function: It behaves
polymorphically, and it has a vtable entry that can be overwritten ==
overridden in a derived class exactly the same as any other derived
virtual override. See also [class.virtual]/7: "Even though destructors
are not inherited, a destructor in a derived class overrides a base
class destructor declared virtual; see [class.dtor] and [class.free]."
However, the following exception text currently appears in C.128:
> If a base class destructor is declared `virtual`, one should avoid
declaring derived class destructors `virtual` or `override`. Some code
base and tools might insist on `override` for destructors, but that is
not the recommendation of these guidelines.
... but this exception is (a) not well-founded, and (b) inconsistent
with the Guidelines' practice in other examples and with the rationale a
few lines earlier for C.128 itself.
Re (a):
- The exception is overly broad: The rationale given for this exception
is entirely against marking destructors `override` (not `virtual`). So
clearly the exception to write neither keyword is too broad: At most,
the exception should be to write `virtual` rather than `override`.
- Explicit `virtual` is primarily for class users, not class authors:
The arguments given in #721 favoring this exception are from the
viewpoint of the implementation of the function (even then, the
arguments are debatable and debated). But `virtual`, `override`, and
`final` are primarily for the far larger audience of *class users and
call sites* of the function, for whom of course we should document each
declared function that is polymorphic, *especially* the destructor --
this tells calling code whether the function is safe to call through a
(smart or built-in) pointer or reference to base, which will nearly
always be the case for such types. We should not make the reader of the
code go way to look in the base classes to figure out whether a function
declared in this class is virtual or not -- the reason this Item exists
is primarily to avoid that implicit virtual antipattern via convention
and automated enforcement. For class users, all virtual functions
including destructors are equally polymorphic.
Re (b): The Guidelines already don't follow this. For instance, two
Items later (in C.130) we have this example that correctly uses
`override`:
~~~
virtual ~D() override;
~~~
... though per C.128 it should not also specify `virtual` (also fixed in
this PR).
Finally, the exception also contradicts the rationale given earlier in
the same Item.
- typo "a" -> "as"
- added "???" to mark incomplete sentence
- typo "than" -> "that"
- "scanf using s" -> "scanf using %s" (same as for printf)
- added missing comma
* ES section, different stuff
- ES.26: same capitalization for all function names in example
- ES.34: fix wrong formatting (first line of example was formatted as text)
- ES.46: corrected value in comment (new value read out in debugger)
- ES.46: Capitalize Enforcement bullet points (as in other ES rules)
- ES.65: fix formatting of code after list (compare https://meta.stackexchange.com/a/34325/172717)
* review-feedback from jwakely
and:
- ES.46/ES.47: added period at end of sentence
* Initial rewrite
* Fixed a couple of inaccuracies and minor grammar mistakes
Thanks to twitter user @lunasorcery for these changes!
* Added toLower to dictionary
- "a C-style, zero-terminated strings" is wrong, it must be either "C-style, zero-terminated strings" or "a C-style, zero-terminated string"
- added hint to `std::string_view
* Add example code for T.48
* Fix whitespace in end of line
* Use better syntax for concept constraint
* Revert "Use better syntax for concept constraint"
This reverts commit f071920d7f.
* reword the A.1 rule title
* add candidate content for the A.1 rule
* make minor improvements to the A.2 note
* simplify wording in the first bullet of A.4's Reason
* 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.
* Standardize example headings
Some example headings used "Example, [good,bad]" and others used
"Example; [good,bad]" (note the comma verses semicolon). The vast
majority of the headings used the comma version, so this commit
normalizes all example headings to use a comma instead of a semicolon.
* Standardize note heading level
Two of the "Note" headings were set to level four, but the rest are at
level 5. Fix the level fours to make them level fives.
The value -2 is signed, so the word "unsigned" is clearly wrong. The
text notes that negative subscripts are a source of surprises and
bugs, so the correction to "negative" seems to reflect Bjarne's
original intent.
