* 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.
Currently these guidelines conflict with R.34, R.35, and R.36.
This conflict has led to confusion, where it's unclear which
guidelines to prefer for `shared_ptr` types.
In a [previous
PR](https://github.com/isocpp/CppCoreGuidelines/pull/1989) I proposed
preferring the "F" series of guidelines. This PR takes the opposite
approach and prefers the "R" guidelines for `shared_ptr` types.
I don't feel strongly about which guidelines to prefer, I just want to make
sure the guidelines are internally consistent.
