mirror of
https://github.com/isocpp/CppCoreGuidelines.git
synced 2025-12-17 12:44:42 +03:00
Restored accidentally overwritten editorial changes
This commit is contained in:
@@ -7909,7 +7909,7 @@ It also ensures exception safety in complex expressions.
|
|||||||
|
|
||||||
##### Example
|
##### Example
|
||||||
|
|
||||||
unique_ptr<Foo> p {new<Foo>{7}}; // OK: but repetitive
|
unique_ptr<Foo> p {new Foo{7}}; // OK: but repetitive
|
||||||
|
|
||||||
auto q = make_unique<Foo>(7); // Better: no repetition of Foo
|
auto q = make_unique<Foo>(7); // Better: no repetition of Foo
|
||||||
|
|
||||||
@@ -7942,7 +7942,7 @@ It also gives an opportunity to eliminate a separate allocation for the referenc
|
|||||||
|
|
||||||
void test() {
|
void test() {
|
||||||
// OK: but repetitive; and separate allocations for the Bar and shared_ptr's use count
|
// OK: but repetitive; and separate allocations for the Bar and shared_ptr's use count
|
||||||
shared_ptr<Bar> p {new<Bar>{7}};
|
shared_ptr<Bar> p {new Bar{7}};
|
||||||
|
|
||||||
auto q = make_shared<Bar>(7); // Better: no repetition of Bar; one object
|
auto q = make_shared<Bar>(7); // Better: no repetition of Bar; one object
|
||||||
}
|
}
|
||||||
@@ -8473,7 +8473,7 @@ So far, so good, but we can easily misuse the `union`:
|
|||||||
cout << v.x << '\n'; // BAD, undefined behavior: v holds a double, but we read it as an int
|
cout << v.x << '\n'; // BAD, undefined behavior: v holds a double, but we read it as an int
|
||||||
|
|
||||||
Note that the type error happened without any explicit cast.
|
Note that the type error happened without any explicit cast.
|
||||||
When we tested that program the last value printed was `1683627180` which it the integer value for the bit pattern for `987.654`.
|
When we tested that program the last value printed was `1683627180` which is the integer value for the bit pattern for `987.654`.
|
||||||
What we have here is an "invisible" type error that happens to give a result that could easily look innocent.
|
What we have here is an "invisible" type error that happens to give a result that could easily look innocent.
|
||||||
|
|
||||||
And, talking about "invisible", this code produced no output:
|
And, talking about "invisible", this code produced no output:
|
||||||
@@ -8727,7 +8727,7 @@ Switching on an enumeration is common and the compiler can warn against unusual
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
Such off-by-one switch`statements are often the results of an added enumerator and insufficient testing.
|
Such off-by-one `switch`statements are often the results of an added enumerator and insufficient testing.
|
||||||
|
|
||||||
##### Enforcement
|
##### Enforcement
|
||||||
|
|
||||||
@@ -10717,7 +10717,7 @@ Use `={...}` if you really want an `initializer_list<T>`
|
|||||||
|
|
||||||
`={}` gives copy initialization whereas `{}` gives direct initialization.
|
`={}` gives copy initialization whereas `{}` gives direct initialization.
|
||||||
Like the distinction between copy-initialization and direct-initialization itself, this can lead to surprises.
|
Like the distinction between copy-initialization and direct-initialization itself, this can lead to surprises.
|
||||||
`{}` accepts `explicit` constructors; `={}` does not`. For example:
|
`{}` accepts `explicit` constructors; `={}` does not. For example:
|
||||||
|
|
||||||
struct Z { explicit Z() {} };
|
struct Z { explicit Z() {} };
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user