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

Fix whitespace around operator

Browse Source
This commit is contained in:
Thibault Kruse 2016-04-23 14:16:59 +02:00
parent da92068a5f
commit d7bab1ab0f
1 changed files with 22 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
CppCoreGuidelines.md
View File

@ -2239,8 +2239,13 @@ Passing a shared smart pointer (e.g., `std::shared_ptr`) implies a run-time cost
##### Example ##### Example
void f(int*); // accepts any int* // accepts any int*
void f(int*);
// can only accept ints for which you want to transfer ownership
void g(unique_ptr<int>); // accepts ints to transfer ownership void g(unique_ptr<int>); // accepts ints to transfer ownership
// can only accept ints for which you are willing to share ownership
void g(shared_ptr<int>); // accepts ints to share ownership void g(shared_ptr<int>); // accepts ints to share ownership
// doesn’t change ownership, but requires a particular ownership of the caller // doesn’t change ownership, but requires a particular ownership of the caller
@ -2683,10 +2688,13 @@ A `span` represents a range of elements, but how do we manipulate elements of th
{ {
// range traversal (guaranteed correct) // range traversal (guaranteed correct)
for (int x : s) cout << x << '\n'; for (int x : s) cout << x << '\n';
// C-style traversal (potentially checked) // C-style traversal (potentially checked)
for (int i = 0; i < s.size(); ++i) cout << x << '\n'; for (int i = 0; i < s.size(); ++i) cout << x << '\n';
// random access (potentially checked) // random access (potentially checked)
s[7] = 9; s[7] = 9;
// extract pointers (potentially checked) // extract pointers (potentially checked)
std::sort(&s[0], &s[s.size() / 2]); std::sort(&s[0], &s[s.size() / 2]);
} }
@ -4064,7 +4072,9 @@ If the `Handle` owns the object referred to by `s` it must have a destructor.
Independently of whether `Handle` owns its `Shape`, we must consider the default copy operations suspect: Independently of whether `Handle` owns its `Shape`, we must consider the default copy operations suspect:
Handle x {*new Circle{p1, 17}}; // causes a leak if the Handle is not a Circle // the Handle had better own the Circle or we have a leak
Handle x {*new Circle{p1, 17}};
Handle y {*new Triangle{p1, p2, p3}}; Handle y {*new Triangle{p1, p2, p3}};
x = y; // the default assignment will try *x.s = *y.s x = y; // the default assignment will try *x.s = *y.s
@ -9279,28 +9289,28 @@ Complicated expressions are error-prone.
##### Example ##### Example
// bad: assignment hidden in subexpression // bad: assignment hidden in subexpression
while ((c = getc()) != -1) while ((c = getc()) != -1)
// bad: two non-local variables assigned in a sub-expressions // bad: two non-local variables assigned in a sub-expressions
while ((cin >> c1, cin >> c2), c1 == c2) while ((cin >> c1, cin >> c2), c1 == c2)
// better, but possibly still too complicated // better, but possibly still too complicated
for (char c1, c2; cin >> c1 >> c2 && c1 == c2;) for (char c1, c2; cin >> c1 >> c2 && c1 == c2;)
// OK: iff i and j are not aliased // OK: iff i and j are not aliased
int x = ++i + ++j; int x = ++i + ++j;
// OK: iff i != j and i != k // OK: iff i != j and i != k
v[i] = v[j] + v[k]; v[i] = v[j] + v[k];
// bad: multiple assignments "hidden" in subexpressions // bad: multiple assignments "hidden" in subexpressions
x = a + (b = f()) + (c = g()) * 7; x = a + (b = f()) + (c = g()) * 7;
// bad: relies on commonly misunderstood precedence rules // bad: relies on commonly misunderstood precedence rules
x = a & b + c * d && e ^ f == 7; x = a & b + c * d && e ^ f == 7;
// bad: undefined behavior // bad: undefined behavior
x = x++ + x++ + ++x; x = x++ + x++ + ++x;
Some of these expressions are unconditionally bad (e.g., they rely on undefined behavior). Others are simply so complicated and/or unusual that even good programmers could misunderstand them or overlook a problem when in a hurry. Some of these expressions are unconditionally bad (e.g., they rely on undefined behavior). Others are simply so complicated and/or unusual that even good programmers could misunderstand them or overlook a problem when in a hurry.
@ -12113,8 +12123,8 @@ In general, passing function objects gives better performance than passing point
You can, of course, generalize those functions using `auto` or (when and where available) concepts. For example: You can, of course, generalize those functions using `auto` or (when and where available) concepts. For example:
auto y1 = find_if(v, [](Ordered x) { return x>7; }); // require an ordered type auto y1 = find_if(v, [](Ordered x) { return x > 7; }); // require an ordered type
auto z1 = find_if(v, [](auto x) { return x>7; }); // hope that the type has a > auto z1 = find_if(v, [](auto x) { return x > 7; }); // hope that the type has a >
##### Note ##### Note