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.
Section C.21 shows a code example which typed
a class name in two different ways:
- CloneableBase
- ClonableBase
It is easy to overlook but it would not compile.
My commit prefers CloneableBase over ClonableBase and uses just that
name then. I prefered CloneableBase because Java's SDK uses the same
writing, so I guess this can be consired to be more widely used.
