Clean up and add example for C.32 - raw pointers (#1909)

* Update CppCoreGuidelines.md

* Update CppCoreGuidelines.md

* Update isocpp.dic

* use snake casing

* sake case naming

* C 32 comments (#3)

* F.16 ("in" parameters): Move Matrix example to F.20 (return values) (#1922)

The `Matrix` example and the notes about assignment appear off-topic in rule F.16, as F.16 is specifically about "in" parameters.

With help from Sergey Zubkov.

* SL.io.50 (Avoid `endl`): Mention string streams (#1920)

Explicitly mentioned string streams as `endl` insertions into string streams do actually occur in the wild.

With help from Sergey Zubkov.

* Extended E.16 to include copy ctor for exception type, closes #1921

* Fix GitHub Actions build warnings, Marker style should be `*` (#1925)

* restored reference

* Added references to note

Co-authored-by: Niels Dekker <N.Dekker@lumc.nl>
Co-authored-by: Herb Sutter <herb.sutter@gmail.com>

Co-authored-by: Niels Dekker <N.Dekker@lumc.nl>
Co-authored-by: Herb Sutter <herb.sutter@gmail.com>
This commit is contained in:
bgloyer
2022-07-13 09:23:14 -07:00
committed by GitHub
parent f2e9b5c2ac
commit cbf455407e
2 changed files with 13 additions and 3 deletions

View File

@@ -4993,12 +4993,19 @@ There is a lot of code that is non-specific about ownership.
##### Example
???
class legacy_class
{
foo* m_owning;
bar* m_observer;
}
The only way to determine ownership may be to dig through the code to look for
allocations. If a pointer or reference is owning, document it as owning.
##### Note
If the `T*` or `T&` is owning, mark it `owning`. If the `T*` is not owning, consider marking it `ptr`.
This will aid documentation and analysis.
Ownership should be clear in new code (and refactored legacy code) according to [R.20](#Rr-owner) for owned
pointers and [R.3](#Rr-ptr) for non-owned pointers. References should never own [R.4](#Rr-ref).
##### Enforcement