diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 0d94010..832fd9c 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -5291,17 +5291,17 @@ A trivial getter or setter adds no semantic value; the data item could just as w public: point(int xx, int yy) : x{xx}, y{yy} { } int get_x() { return x; } - void set_x(int xx) { x = xx; } + void set_x(int xx) { x = xx; } int get_y() { return y; } - void set_y(int yy) { y = yy; } - // no behavioral member functions + void set_y(int yy) { y = yy; } + // no behavioral member functions }; Consider making such a class a `struct` -- that is, a behaviorless bunch of variables, all public data and no member functions. struct point { - int x = 0; - int y = 0; + int x = 0; + int y = 0; }; ##### Note @@ -8680,12 +8680,12 @@ Performance is very sensitive to cache performance and cache algorithms favor si ##### Example int matrix[rows][cols]; - + //bad for(int c=0; c p = D::Create(); // creating a D object + shared_ptr p = D::Create(); // creating a D object This design requires the following discipline: @@ -12954,8 +12954,7 @@ Here, if constructing `copy2` throws, we have the same problem because `i`'s des void test() { std::array arr; // this line can std::terminate(!) - -} + } The behavior of arrays is undefined in the presence of destructors that throw because there is no reasonable rollback behavior that could ever be devised. Just think: What code can the compiler generate for constructing an `arr` where, if the fourth object's constructor throws, the code has to give up and in its cleanup mode tries to call the destructors of the already-constructed objects... and one or more of those destructors throws? There is no satisfactory answer. @@ -13219,7 +13218,7 @@ To simplify code and eliminate a need for explicit memory management. To bring a { return ...; } - + auto v = get_large_vector(); //return by value is ok, most modern compilers will do copy elision ##### Example