Skip to content

Commit ddef6cd

Browse files
authored
Move F.60 to align with TOC (#1914)
1 parent e30543d commit ddef6cd

File tree

1 file changed

+33
-33
lines changed

1 file changed

+33
-33
lines changed

CppCoreGuidelines.md

Lines changed: 33 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -3230,6 +3230,39 @@ Another example, use a specific type along the lines of `variant<T, error_code>`
32303230
* Output parameters should be replaced by return values.
32313231
An output parameter is one that the function writes to, invokes a non-`const` member function, or passes on as a non-`const`.
32323232

3233+
### <a name="Rf-ptr-ref"></a>F.60: Prefer `T*` over `T&` when "no argument" is a valid option
3234+
3235+
##### Reason
3236+
3237+
A pointer (`T*`) can be a `nullptr` and a reference (`T&`) cannot, there is no valid "null reference".
3238+
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.
3239+
3240+
##### Example
3241+
3242+
string zstring_to_string(zstring p) // zstring is a char*; that is a C-style string
3243+
{
3244+
if (!p) return string{}; // p might be nullptr; remember to check
3245+
return string{p};
3246+
}
3247+
3248+
void print(const vector<int>& r)
3249+
{
3250+
// r refers to a vector<int>; no check needed
3251+
}
3252+
3253+
##### Note
3254+
3255+
It is possible, but not valid C++ to construct a reference that is essentially a `nullptr` (e.g., `T* p = nullptr; T& r = *p;`).
3256+
That error is very uncommon.
3257+
3258+
##### Note
3259+
3260+
If you prefer the pointer notation (`->` and/or `*` vs. `.`), `not_null<T*>` provides the same guarantee as `T&`.
3261+
3262+
##### Enforcement
3263+
3264+
* Flag ???
3265+
32333266
### <a name="Rf-ptr"></a>F.22: Use `T*` or `owner<T*>` to designate a single object
32343267

32353268
##### Reason
@@ -3468,39 +3501,6 @@ Have a single object own the shared object (e.g. a scoped object) and destroy th
34683501

34693502
(Not enforceable) This is a too complex pattern to reliably detect.
34703503

3471-
### <a name="Rf-ptr-ref"></a>F.60: Prefer `T*` over `T&` when "no argument" is a valid option
3472-
3473-
##### Reason
3474-
3475-
A pointer (`T*`) can be a `nullptr` and a reference (`T&`) cannot, there is no valid "null reference".
3476-
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.
3477-
3478-
##### Example
3479-
3480-
string zstring_to_string(zstring p) // zstring is a char*; that is a C-style string
3481-
{
3482-
if (!p) return string{}; // p might be nullptr; remember to check
3483-
return string{p};
3484-
}
3485-
3486-
void print(const vector<int>& r)
3487-
{
3488-
// r refers to a vector<int>; no check needed
3489-
}
3490-
3491-
##### Note
3492-
3493-
It is possible, but not valid C++ to construct a reference that is essentially a `nullptr` (e.g., `T* p = nullptr; T& r = *p;`).
3494-
That error is very uncommon.
3495-
3496-
##### Note
3497-
3498-
If you prefer the pointer notation (`->` and/or `*` vs. `.`), `not_null<T*>` provides the same guarantee as `T&`.
3499-
3500-
##### Enforcement
3501-
3502-
* Flag ???
3503-
35043504
### <a name="Rf-return-ptr"></a>F.42: Return a `T*` to indicate a position (only)
35053505

35063506
##### Reason

0 commit comments

Comments
 (0)