StarMirror/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2024-03-22 13:30:58 +08:00
Code Issues Projects Releases Wiki Activity

make 'side effect' vs. 'side-effect' spelling consistent

Browse Source
This commit is contained in:
Thibault Kruse 2017-06-25 12:36:14 +09:00
parent 172520b570
commit ba82be70bd
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
CppCoreGuidelines.md
View File

@ -2565,7 +2565,7 @@ it just guarantees that the function can be evaluated at compile time for consta
This is usually a very good thing. This is usually a very good thing.
When given a non-constant argument, a `constexpr` function can throw. When given a non-constant argument, a `constexpr` function can throw.
If you consider exiting by throwing a side-effect, a `constexpr` function isn't completely pure; If you consider exiting by throwing a side effect, a `constexpr` function isn't completely pure;
if not, this is not an issue. if not, this is not an issue.
??? A question for the committee: can a constructor for an exception thrown by a `constexpr` function modify state? ??? A question for the committee: can a constructor for an exception thrown by a `constexpr` function modify state?
"No" would be a nice answer that matches most practice. "No" would be a nice answer that matches most practice.
@ -2751,7 +2751,7 @@ Pure functions are easier to reason about, sometimes easier to optimize (and eve
`constexpr` functions are pure. `constexpr` functions are pure.
When given a non-constant argument, a `constexpr` function can throw. When given a non-constant argument, a `constexpr` function can throw.
If you consider exiting by throwing a side-effect, a `constexpr` function isn't completely pure; If you consider exiting by throwing a side effect, a `constexpr` function isn't completely pure;
if not, this is not an issue. if not, this is not an issue.
??? A question for the committee: can a constructor for an exception thrown by a `constexpr` function modify state? ??? A question for the committee: can a constructor for an exception thrown by a `constexpr` function modify state?
"No" would be a nice answer that matches most practice. "No" would be a nice answer that matches most practice.
@ -10746,7 +10746,7 @@ Readability. Error prevention. Efficiency.
for (int i = 1; i < v.size(); ++i) // touches two elements: can't be a range-for for (int i = 1; i < v.size(); ++i) // touches two elements: can't be a range-for
cout << v[i] + v[i - 1] << '\n'; cout << v[i] + v[i - 1] << '\n';
for (int i = 0; i < v.size(); ++i) // possible side-effect: can't be a range-for for (int i = 0; i < v.size(); ++i) // possible side effect: can't be a range-for
cout << f(v, &v[i]) << '\n'; cout << f(v, &v[i]) << '\n';
for (int i = 0; i < v.size(); ++i) { // body messes with loop variable: can't be a range-for for (int i = 0; i < v.size(); ++i) { // body messes with loop variable: can't be a range-for
@ -10776,7 +10776,7 @@ Better still, if the loop variable isn't modified or copied:
##### Enforcement ##### Enforcement
Look at loops, if a traditional loop just looks at each element of a sequence, and there are no side-effects on what it does with the elements, rewrite the loop to a ranged-`for` loop. Look at loops, if a traditional loop just looks at each element of a sequence, and there are no side effects on what it does with the elements, rewrite the loop to a ranged-`for` loop.
### <a name="Res-for-while"></a>ES.72: Prefer a `for`-statement to a `while`-statement when there is an obvious loop variable ### <a name="Res-for-while"></a>ES.72: Prefer a `for`-statement to a `while`-statement when there is an obvious loop variable