StarMirror/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2024-03-22 13:30:58 +08:00
Code Issues Projects Releases Wiki Activity

Improved R.3 note wording to help address PR #417.

Browse Source
This commit is contained in:
hsutter 2015-12-29 11:15:04 -08:00
parent 13c8df9abc
commit 7cd72691e8
1 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
CppCoreGuidelines.md
View File

@ -6749,12 +6749,13 @@ We can fix that problem by making ownership explicit:
T* q; // OK: q is not owning T* q; // OK: q is not owning
}; };
##### Note ##### Exceptions
A major class of exception is legacy code, especially code that must remain compilable as C.
The fact that there are billions of lines of code that violate this rule against owning `T*`s cannot be ignored. The fact that there are billions of lines of code that violate this rule against owning `T*`s cannot be ignored.
This code cannot all be rewritten (ever assuming good code transformation software). This code cannot all be rewritten (ever assuming good code transformation software).
This problem cannot be solved (at scale) by transforming all owning pointer to `unique_ptr`s and `shared_ptr`s, partly because we need/use owning "raw pointers" in the implementation of our fundamental resource handles. For example, most `vector` implementations have one owning pointer and two non-owning pointers. This problem cannot be solved (at scale) by transforming all owning pointers to `unique_ptr`s and `shared_ptr`s, partly because we need/use owning "raw pointers" in the implementation of our fundamental resource handles. For example, common `vector` implementations have one owning pointer and two non-owning pointers.
Also, many ABIs (and essentially all interfaces to C code) use `T*`s, some of them owning. Also, many ABIs (and essentially all interfaces to C code) use `T*`s, some of them owning, and these cannot be simply annotated with `owner` because they need to remain compilable as C (although this would be a rare good use for a macro, that expands to `owner` in C++ mode only).
##### Note ##### Note