Added missing periods in various parts of the text to ensure consistency and correctness in writing style. This revision maintains uniform formatting throughout the document, improves readability, and aligns the punctuation with the rest of the content for a more polished and structured appearance.
* fix incorrect reason for F.48
* distinguish rvo and nrvo
* the issue is about local, so limiting example to local
---------
Co-authored-by: Sergey Zubkov <cubbi@cubbi.com>
The second ES.87 example seemed to mistakenly assume that `Circle` is pointer type, by the way it was using `dynamic_cast`. However, `Circle` is meant to be a class type instead. This fix is consistent with other examples, that also do `dynamic_cast<Circle*>`.
* ES.30 fix example code
The example should be passing in a constexpr and validating it at compile time like a macro, but instead passes a unknown value at compile time. Which may cause mislead and the code doesn't even work.
Ref: #2136
* Update CppCoreGuidelines.md
Used enums instead of raw numbers.
* SF.13 Use portable header identifiers in `#include` statements
add a new rule governing how to compose portable header path identifiers such that they respect proper casing (<vector>, not <VECTOR>) and portable path separators ('/')
* anchor
* fix typos
* fix warnings
* nit
* nit
* nit
* normalize on 'util'
* clean up wording
* Update CppCoreGuidelines.md
---------
Co-authored-by: Herb Sutter <herb.sutter@gmail.com>
The example suggests that `int z = gsl::narrow_cast<int>(7.9);;` is OK. The rule says "Use `=` only when you are sure that there can be no narrowing conversions.", which matches, but is also says "For built-in arithmetic types, use `=` only with `auto`.", and this is not respected here. So replace the one line with both possibilities suggested by the rule.
Co-authored-by: Werner Henze <w.henze@avm.de>
C.65 requires move assignment to be safe for self-assignment. The given example is not safe for self-assignment as given right now. This commit fixes this.
Co-authored-by: Werner Henze <w.henze@avm.de>
The original text was "If the `new` and the `delete` are in the same scope, mistakes can be flagged." This has been [misinterpreted](https://stackoverflow.com/q/75905524) to mean "Any `new` and `delete` in the same scope is a mistake and should be flagged."
Reword the Enforcement clauses to follow the pattern established by the other Enforcement clauses: "Flag (bad thing)". Also, call the issue a "mismatch" rather than a "mistake", so that it is more clear that the underlying issue is the mismatch between scalar and array new/deletion.
