@@ -4222,7 +4222,7 @@ For example, a derived class might be allowed to skip a run-time check because i
42224222
42234223 class Foo {
42244224 public:
4225- int bar(int x) { check(x); return do_bar(); }
4225+ int bar(int x) { check(x); return do_bar(x ); }
42264226 // ...
42274227 protected:
42284228 int do_bar(int x); // do some operation on the data
@@ -4238,7 +4238,7 @@ For example, a derived class might be allowed to skip a run-time check because i
42384238 /* ... do something ... */
42394239 return do_bar(x + y); // OK: derived class can bypass check
42404240 }
4241- }
4241+ };
42424242
42434243 void user(Foo& x)
42444244 {
@@ -7126,7 +7126,7 @@ If the operations are virtual the use of inheritance is necessary, if not using
71267126
71277127##### Example
71287128
7129- class iostream : public istream, public ostream { // very simplified
7129+ class iostream : public istream, public ostream { // very simplified
71307130 // ...
71317131 };
71327132
@@ -7611,10 +7611,12 @@ It also gives an opportunity to eliminate a separate allocation for the referenc
76117611
76127612##### Example
76137613
7614- // OK: but repetitive; and separate allocations for the Foo and shared_ptr's use count
7615- shared_ptr<Foo> p {new<Foo>{7}};
7614+ void test() {
7615+ // OK: but repetitive; and separate allocations for the Bar and shared_ptr's use count
7616+ shared_ptr<Bar> p {new<Bar>{7}};
76167617
7617- auto q = make_shared<Foo>(7); // Better: no repetition of Foo; one object
7618+ auto q = make_shared<Bar>(7); // Better: no repetition of Bar; one object
7619+ }
76187620
76197621##### Enforcement
76207622
@@ -8978,9 +8980,9 @@ If you don't, an exception or a return may lead to a leak.
89788980
89798981 void f(const string& name)
89808982 {
8981- FILE* f = fopen(name, "r"); // open the file
8983+ FILE* f = fopen(name, "r"); // open the file
89828984 vector<char> buf(1024);
8983- auto _ = finally([f] { fclose(f); }) // remember to close the file
8985+ auto _ = finally([f] { fclose(f); }); // remember to close the file
89848986 // ...
89858987 }
89868988
@@ -10914,7 +10916,7 @@ There is a fair amount of use of the C goto-exit idiom:
1091410916 goto exit;
1091510917 // ...
1091610918 exit:
10917- ... common cleanup code ...
10919+ // ... common cleanup code ...
1091810920 }
1091910921
1092010922This is an ad-hoc simulation of destructors.
@@ -11367,7 +11369,7 @@ Use a `span`:
1136711369
1136811370 void f2(array<int, 10> arr, int pos) // A2: Add local span and use that
1136911371 {
11370- span<int> a = {arr, pos}
11372+ span<int> a = {arr, pos};
1137111373 a[pos / 2] = 1; // OK
1137211374 a[pos - 1] = 2; // OK
1137311375 }
@@ -12248,7 +12250,7 @@ The conventional resolution is to interpret `{10}` as a list of one element and
1224812250This mistake need not be repeated in new code.
1224912251We can define a type to represent the number of elements:
1225012252
12251- struct Count { int n };
12253+ struct Count { int n; };
1225212254
1225312255 template<typename T>
1225412256 class Vector {
@@ -12670,7 +12672,7 @@ For example
1267012672 operator int() { return val; }
1267112673 };
1267212674
12673- int f(Positive arg) {return arg };
12675+ int f(Positive arg) { return arg; }
1267412676
1267512677 int r1 = f(2);
1267612678 int r2 = f(-2); // throws
@@ -13321,7 +13323,7 @@ The less sharing you do, the less chance you have to wait on a lock (so performa
1332113323 socket1 >> surface_readings;
1332213324 if (!socket1) throw Bad_input{};
1332313325
13324- auto h1 = async([&] { if (!validate(surface_readings) throw Invalid_data{}; });
13326+ auto h1 = async([&] { if (!validate(surface_readings)) throw Invalid_data{}; });
1332513327 auto h2 = async([&] { return temperature_gradiants(surface_readings); });
1332613328 auto h3 = async([&] { return altitude_map(surface_readings); });
1332713329 // ...
@@ -13887,7 +13889,7 @@ message passing or shared memory.
1388713889???
1388813890
1388913891
13890- ### <a name="Rconc-shared"></a>[ CP.32: To share ownership between unrelated `thread`s use `shared_ptr`
13892+ ### <a name="Rconc-shared"></a>CP.32: To share ownership between unrelated `thread`s use `shared_ptr`
1389113893
1389213894##### Reason
1389313895
@@ -14709,7 +14711,7 @@ RAII ("Resource Acquisition Is Initialization") is the simplest, most systematic
1470914711 {
1471014712 int* p = new int[12];
1471114713 // ...
14712- if (i < 17) throw Bad {"in f()", i};
14714+ if (i < 17) throw Bad{"in f()", i};
1471314715 // ...
1471414716 }
1471514717
@@ -14721,7 +14723,7 @@ We could carefully release the resource before the throw:
1472114723 // ...
1472214724 if (i < 17) {
1472314725 delete[] p;
14724- throw Bad {"in f()", i};
14726+ throw Bad{"in f()", i};
1472514727 }
1472614728 // ...
1472714729 }
@@ -14732,7 +14734,7 @@ This is verbose. In larger code with multiple possible `throw`s explicit release
1473214734 {
1473314735 auto p = make_unique<int[]>(12);
1473414736 // ...
14735- if (i < 17) throw Bad {"in f()", i};
14737+ if (i < 17) throw Bad{"in f()", i};
1473614738 // ...
1473714739 }
1473814740
@@ -14990,11 +14992,13 @@ To prevent slicing.
1499014992##### Example
1499114993
1499214994 void f()
14993- try {
14994- // ...
14995- }
14996- catch (exception e) { // don't: may slice
14997- // ...
14995+ {
14996+ try {
14997+ // ...
14998+ }
14999+ catch (exception e) { // don't: may slice
15000+ // ...
15001+ }
1499815002 }
1499915003
1500015004Instead, use a reference:
@@ -15592,7 +15596,7 @@ You can
1559215596Example:
1559315597
1559415598 void f(int* p); // old code: f() does not modify `*p`
15595- void f(const int* p) { f(const_cast<int*>(p); } // wrapper
15599+ void f(const int* p) { f(const_cast<int*>(p)) ; } // wrapper
1559615600
1559715601Note that this wrapper solution is a patch that should be used only when the declaration of `f()` cannot be be modified,
1559815602e.g. because it is in a library that you cannot modify.
@@ -16296,13 +16300,13 @@ It is a general design rule that even applies to non-templates:
1629616300
1629716301 void f(const Minimal& x, const Minimal& y)
1629816302 {
16299- if (!(x == y) { /* ... */ } // OK
16303+ if (!(x == y)) { /* ... */ } // OK
1630016304 if (x != y) { /* ... */ } // surprise! error
1630116305
1630216306 while (!(x < y)) { /* ... */ } // OK
1630316307 while (x >= y) { /* ... */ } // surprise! error
1630416308
16305- x = x + y; // OK
16309+ x = x + y; // OK
1630616310 x += y; // surprise! error
1630716311 }
1630816312
@@ -16326,14 +16330,14 @@ The rule supports the view that a concept should reflect a (mathematically) cohe
1632616330
1632716331 void f(const Convenient& x, const Convenient& y)
1632816332 {
16329- if (!(x == y) { /* ... */ } // OK
16333+ if (!(x == y)) { /* ... */ } // OK
1633016334 if (x != y) { /* ... */ } // OK
1633116335
1633216336 while (!(x < y)) { /* ... */ } // OK
1633316337 while (x >= y) { /* ... */ } // OK
1633416338
1633516339 x = x + y; // OK
16336- x += y; // OK
16340+ x += y; // OK
1633716341 }
1633816342
1633916343It can be a nuisance to define all operators, but not hard.
@@ -18690,7 +18694,7 @@ Don't use C-style strings for operations that require non-trivial memory managem
1869018694 p[l1] = '.';
1869118695 strcpy(p + l1 + 1, s2, l2);
1869218696 p[l1 + l2 + 1] = 0;
18693- return res ;
18697+ return p ;
1869418698 }
1869518699
1869618700Did we get that right?
@@ -19356,7 +19360,7 @@ This technique is a pre-exception technique for RAII-like resource and error han
1935619360 // ...
1935719361 int* p = (int*) malloc(n);
1935819362 // ...
19359- if (some_ error ) goto_exit;
19363+ if (some_error ) goto_exit;
1936019364 // ...
1936119365 exit:
1936219366 free(p);
0 commit comments