Skip to content

Commit f9ebe1f

Browse files
committed
Fix missing open braces escape and missing backticks
1 parent c8a1831 commit f9ebe1f

File tree

1 file changed

+14
-13
lines changed

1 file changed

+14
-13
lines changed

CppCoreGuidelines.md

Lines changed: 14 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1602,7 +1602,7 @@ Consider:
16021602
// ...
16031603
draw(arr, 10);
16041604

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.
16061606

16071607
**Alternative**: Use a support class that ensures that the number of elements is correct and prevents dangerous implicit conversions. For example:
16081608

@@ -2450,8 +2450,8 @@ In that case, and only that case, make the parameter `TP&&` where `TP` is a temp
24502450
??? calls ???
24512451

24522452
##### 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.
24542453

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.
24552455

24562456
### <a name="Rf-out"></a>F.20: For "out" output values, prefer return values to output parameters
24572457

@@ -2645,9 +2645,9 @@ Informal/non-explicit ranges are a source of errors.
26452645
##### Note
26462646

26472647
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`),
26492649
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.
26512651

26522652
##### Example
26532653

@@ -5449,12 +5449,12 @@ The alternative is to make two failure states compare equal and any valid state
54495449

54505450
#### Note
54515451

5452-
This rule applies to all the usual comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5452+
This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
54535453

54545454
##### Enforcement
54555455

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 `>=`.
54585458

54595459
### <a name="Rc-eq-base"></a>C.87: Beware of `==` on base classes
54605460

@@ -5498,11 +5498,11 @@ Of course there are ways of making `==` work in a hierarchy, but the naive appro
54985498

54995499
#### Note
55005500

5501-
This rule applies to all the usual comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5501+
This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
55025502

55035503
##### Enforcement
55045504

5505-
* Flag a virtual `operator==()`; same for other comparison operators: `!=', `<, `<=`, `>`, and `>=`.
5505+
* Flag a virtual `operator==()`; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
55065506

55075507

55085508

@@ -5535,6 +5535,7 @@ It's a standard-library requirement.
55355535
m[mt] = 7;
55365536
cout << m[My_type{ "asdfg" }] << '\n';
55375537
}
5538+
55385539
If you have to define a `hash` specialization, try simply to let it combine standard-library `hash` specializations with `^` (xor).
55395540
That tends to work better than "cleverness" for non-specialists.
55405541

@@ -6639,7 +6640,7 @@ Many parts of the C++ semantics assumes its default meaning.
66396640

66406641
If you "mess with" operator `&` be sure that its definition has matching meanings for `->`, `[]`, `*`, and `.` on the result type.
66416642
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>.
66436644
Note that `std::addressof()` always yields a built-in pointer.
66446645

66456646
##### Enforcement
@@ -9616,7 +9617,7 @@ And after you do that, assume the object has been moved from (see [C.64](#Rc-mov
96169617
##### Notes
96179618

96189619
`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.
96209621

96219622
Never write `std::move()` just because you've heard "it's more efficient."
96229623
In general, don't believe claims of "efficiency" without data (???).
@@ -14342,8 +14343,8 @@ If something is not supposed to be `nullptr`, say so:
1434214343
* `not_null<T>` // `T` is usually a pointer type (e.g., `not_null<int*>` and `not_null<owner<Foo*>>`) that may not be `nullptr`.
1434314344
`T` can be any type for which `==nullptr` is meaningful.
1434414345

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
1434714348
* `string_span` // `span<char>`
1434814349
* `cstring_span` // `span<const char>`
1434914350

0 commit comments

Comments
 (0)