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

Modify ES.20 to address #1400

Browse Source
This commit is contained in:
Bjarne Stroustrup
2019-12-08 12:19:24 -05:00
parent 1fdd7e2869
commit b06e365c9f
1 changed files with 27 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
CppCoreGuidelines.md
View File

@@ -10528,6 +10528,31 @@ Assuming that there is a logical connection between `i` and `j`, that connection
auto [i, j] = make_related_widgets(cond); // C++17
If the `make_related_widgets` function is otherwise redundant,
we can eliminate it by using a lambda [ES.28](#Res-lambda-init):
auto [i, j] = [x]{ return (x) ? pair{f1(),f2()} : pair{f3(),f4()} }(); // C++17
Using a value representing "uninitialized" is a symptom of a problem and not a solution:
widget i = uninit; // bad
widget j = uninit;
// ...
use(i); // possibly used before set
// ...
if (cond) { // bad: i and j are initialized "late"
i = f1();
j = f2();
}
else {
i = f3();
j = f4();
}
Now the compiler cannot even simply detect a used-before-set. Further, we've introduced complexity in the state space for widget: which operations are valid on an `uninit` widget and which are not?
##### Note
Complex initialization has been popular with clever programmers for decades.
@@ -10573,6 +10598,8 @@ However, such examples do tend to leave uninitialized variables accessible, so t
int buf[max] = {}; // zero all elements; better in some situations
f.read(buf, max);
Because of the restrictive initialization rules for arrays and `std::array`, they offer the most commoncompelling examples of the need for this exception.
When feasible use a library function that is known not to overflow. For example:
string s; // s is default initialized to ""
@@ -10592,27 +10619,6 @@ In the not uncommon case where the input target and the input operation get sepa
A good optimizer should know about input operations and eliminate the redundant operation.
##### Example
Using a value representing "uninitialized" is a symptom of a problem and not a solution:
widget i = uninit; // bad
widget j = uninit;
// ...
use(i); // possibly used before set
// ...
if (cond) { // bad: i and j are initialized "late"
i = f1();
j = f2();
}
else {
i = f3();
j = f4();
}
Now the compiler cannot even simply detect a used-before-set. Further, we've introduced complexity in the state space for widget: which operations are valid on an `uninit` widget and which are not?
##### Note