Mirrors/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2025-12-17 12:44:42 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

Move F.60 to align with TOC (#1914)

Browse Source
This commit is contained in:
Markus Hofbauer
2022-05-19 23:05:04 +02:00
committed by GitHub
parent e30543d06a
commit ddef6cdbae
1 changed files with 33 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
CppCoreGuidelines.md
View File

@@ -3230,6 +3230,39 @@ Another example, use a specific type along the lines of `variant<T, error_code>`
* Output parameters should be replaced by return values. * Output parameters should be replaced by return values.
An output parameter is one that the function writes to, invokes a non-`const` member function, or passes on as a non-`const`. An output parameter is one that the function writes to, invokes a non-`const` member function, or passes on as a non-`const`.
### <a name="Rf-ptr-ref"></a>F.60: Prefer `T*` over `T&` when "no argument" is a valid option
##### Reason
A pointer (`T*`) can be a `nullptr` and a reference (`T&`) cannot, there is no valid "null reference".
Sometimes having `nullptr` as an alternative to indicated "no object" is useful, but if it is not, a reference is notationally simpler and might yield better code.
##### Example
string zstring_to_string(zstring p) // zstring is a char*; that is a C-style string
{
if (!p) return string{}; // p might be nullptr; remember to check
return string{p};
}
void print(const vector<int>& r)
{
// r refers to a vector<int>; no check needed
}
##### Note
It is possible, but not valid C++ to construct a reference that is essentially a `nullptr` (e.g., `T* p = nullptr; T& r = *p;`).
That error is very uncommon.
##### Note
If you prefer the pointer notation (`->` and/or `*` vs. `.`), `not_null<T*>` provides the same guarantee as `T&`.
##### Enforcement
* Flag ???
### <a name="Rf-ptr"></a>F.22: Use `T*` or `owner<T*>` to designate a single object ### <a name="Rf-ptr"></a>F.22: Use `T*` or `owner<T*>` to designate a single object
##### Reason ##### Reason
@@ -3468,39 +3501,6 @@ Have a single object own the shared object (e.g. a scoped object) and destroy th
(Not enforceable) This is a too complex pattern to reliably detect. (Not enforceable) This is a too complex pattern to reliably detect.
### <a name="Rf-ptr-ref"></a>F.60: Prefer `T*` over `T&` when "no argument" is a valid option
##### Reason
A pointer (`T*`) can be a `nullptr` and a reference (`T&`) cannot, there is no valid "null reference".
Sometimes having `nullptr` as an alternative to indicated "no object" is useful, but if it is not, a reference is notationally simpler and might yield better code.
##### Example
string zstring_to_string(zstring p) // zstring is a char*; that is a C-style string
{
if (!p) return string{}; // p might be nullptr; remember to check
return string{p};
}
void print(const vector<int>& r)
{
// r refers to a vector<int>; no check needed
}
##### Note
It is possible, but not valid C++ to construct a reference that is essentially a `nullptr` (e.g., `T* p = nullptr; T& r = *p;`).
That error is very uncommon.
##### Note
If you prefer the pointer notation (`->` and/or `*` vs. `.`), `not_null<T*>` provides the same guarantee as `T&`.
##### Enforcement
* Flag ???
### <a name="Rf-return-ptr"></a>F.42: Return a `T*` to indicate a position (only) ### <a name="Rf-return-ptr"></a>F.42: Return a `T*` to indicate a position (only)
##### Reason ##### Reason