You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CppCoreGuidelines.md
+14-13Lines changed: 14 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -1602,7 +1602,7 @@ Consider:
1602
1602
// ...
1603
1603
draw(arr, 10);
1604
1604
1605
-
Passing `10` as the `n` argument may be a mistake: the most common convention is to assume [`0`:`n`) but that is nowhere stated. Worse is that the call of `draw()` compiled at all: there was an implicit conversion from array to pointer (array decay) and then another implicit conversion from `Circle` to `Shape`. There is no way that `draw()` can safely iterate through that array: it has no way of knowing the size of the elements.
1605
+
Passing `10` as the `n` argument may be a mistake: the most common convention is to assume \[`0`:`n`) but that is nowhere stated. Worse is that the call of `draw()` compiled at all: there was an implicit conversion from array to pointer (array decay) and then another implicit conversion from `Circle` to `Shape`. There is no way that `draw()` can safely iterate through that array: it has no way of knowing the size of the elements.
1606
1606
1607
1607
**Alternative**: Use a support class that ensures that the number of elements is correct and prevents dangerous implicit conversions. For example:
1608
1608
@@ -2450,8 +2450,8 @@ In that case, and only that case, make the parameter `TP&&` where `TP` is a temp
2450
2450
??? calls ???
2451
2451
2452
2452
##### Enforcement
2453
-
* Flag a function that takes a `TP&&` parameter (where `TP` is a template type parameter name) and does anything with it other than `std::forward`ing it exactly once on every static path.
2454
2453
2454
+
* Flag a function that takes a `TP&&` parameter (where `TP` is a template type parameter name) and does anything with it other than `std::forward`ing it exactly once on every static path.
2455
2455
2456
2456
### <a name="Rf-out"></a>F.20: For "out" output values, prefer return values to output parameters
2457
2457
@@ -2645,9 +2645,9 @@ Informal/non-explicit ranges are a source of errors.
2645
2645
##### Note
2646
2646
2647
2647
Ranges are extremely common in C++ code. Typically, they are implicit and their correct use is very hard to ensure.
2648
-
In particular, given a pair of arguments `(p, n)` designating an array [`p`:`p+n`),
2648
+
In particular, given a pair of arguments `(p, n)` designating an array \[`p`:`p+n`),
2649
2649
it is in general impossible to know if there really are `n` elements to access following `*p`.
2650
-
`span<T>` and `span_p<T>` are simple helper classes designating a [`p`:`q`) range and a range starting with `p` and ending with the first element for which a predicate is true, respectively.
2650
+
`span<T>` and `span_p<T>` are simple helper classes designating a \[`p`:`q`) range and a range starting with `p` and ending with the first element for which a predicate is true, respectively.
2651
2651
2652
2652
##### Example
2653
2653
@@ -5449,12 +5449,12 @@ The alternative is to make two failure states compare equal and any valid state
5449
5449
5450
5450
#### Note
5451
5451
5452
-
This rule applies to all the usual comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5452
+
This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
5453
5453
5454
5454
##### Enforcement
5455
5455
5456
-
* Flag an `operator==()` for which the argument types differ; same for other comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5457
-
* Flag member `operator==()`s; same for other comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5456
+
* Flag an `operator==()` for which the argument types differ; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
5457
+
* Flag member `operator==()`s; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
5458
5458
5459
5459
### <a name="Rc-eq-base"></a>C.87: Beware of `==` on base classes
5460
5460
@@ -5498,11 +5498,11 @@ Of course there are ways of making `==` work in a hierarchy, but the naive appro
5498
5498
5499
5499
#### Note
5500
5500
5501
-
This rule applies to all the usual comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5501
+
This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
5502
5502
5503
5503
##### Enforcement
5504
5504
5505
-
* Flag a virtual `operator==()`; same for other comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5505
+
* Flag a virtual `operator==()`; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
5506
5506
5507
5507
5508
5508
@@ -5535,6 +5535,7 @@ It's a standard-library requirement.
5535
5535
m[mt] = 7;
5536
5536
cout << m[My_type{ "asdfg" }] << '\n';
5537
5537
}
5538
+
5538
5539
If you have to define a `hash` specialization, try simply to let it combine standard-library `hash` specializations with `^` (xor).
5539
5540
That tends to work better than "cleverness" for non-specialists.
5540
5541
@@ -6639,7 +6640,7 @@ Many parts of the C++ semantics assumes its default meaning.
6639
6640
6640
6641
If you "mess with" operator `&` be sure that its definition has matching meanings for `->`, `[]`, `*`, and `.` on the result type.
6641
6642
Note that operator `.` currently cannot be overloaded so a perfect system is impossible.
6642
-
We hope to remedy that: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4477.pdf.
6643
+
We hope to remedy that: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4477.pdf>.
6643
6644
Note that `std::addressof()` always yields a built-in pointer.
6644
6645
6645
6646
##### Enforcement
@@ -9616,7 +9617,7 @@ And after you do that, assume the object has been moved from (see [C.64](#Rc-mov
9616
9617
##### Notes
9617
9618
9618
9619
`std::move()` is a cast to `&&` in disguise; it doesn't itself move anything, but marks a named object as a candidate that can be moved from.
9619
-
The language already knows the common cases where objects can be moved from, especially when returning values from functions, so don't complicate code with redundant `std::move()'s.
9620
+
The language already knows the common cases where objects can be moved from, especially when returning values from functions, so don't complicate code with redundant `std::move()`'s.
9620
9621
9621
9622
Never write `std::move()` just because you've heard "it's more efficient."
9622
9623
In general, don't believe claims of "efficiency" without data (???).
@@ -14342,8 +14343,8 @@ If something is not supposed to be `nullptr`, say so:
14342
14343
* `not_null<T>` // `T` is usually a pointer type (e.g., `not_null<int*>` and `not_null<owner<Foo*>>`) that may not be `nullptr`.
14343
14344
`T` can be any type for which `==nullptr` is meaningful.
14344
14345
14345
-
* `span<T>` // [`p`:`p+n`), constructor from `{p, q}` and `{p, n}`; `T` is the pointer type
14346
-
* `span_p<T>` // `{p, predicate}` [`p`:`q`) where `q` is the first element for which `predicate(*p)` is true
14346
+
* `span<T>` // \[`p`:`p+n`), constructor from `{p, q}` and `{p, n}`; `T` is the pointer type
14347
+
* `span_p<T>` // `{p, predicate}` \[`p`:`q`) where `q` is the first element for which `predicate(*p)` is true
0 commit comments