![\"mathematics](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/03\/mathematics-678969_640.png\")
Four rules to statements are left. Here are they:<\/p>\nToday, I will write about the remaining rules to statements and the arithmetic rules. If you don’t follow the arithmetic rules, undefined behaviour may kick in.<\/p>\n
<\/p>\n
<\/p>\n
Four rules to statements are left. Here are they:<\/p>\n
==<\/code> or !=<\/code> to conditions<\/a><\/li>\n<\/ul>\n The first rule is quite obvious.<\/p>\n
<\/span>ES.84: Don\u2019t (try to) declare a local variable with no name<\/a><\/span><\/h3>\nDeclaring a local variable without a name has no effect. With the final semicolon, the variable will go out of scope.<\/p>\n
\nvoid<\/span> f<\/span>()\r\n{\r\n lock<<\/span>mutex><\/span>{mx}; \/\/ Bad<\/span>\r\n \/\/ critical region<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Typically, the optimizer can remove the creation of a temporary, if it will not change the observable behavior of the program. This is the so-called as-if<\/a> rule. To put it the other way around. If the constructor has observable behavior such as modifying the global state of the program, the optimizer is not allowed to remove the creation of the temporary.<\/p>\n<\/span>ES.85: Make empty statements visible<\/a><\/span><\/h3>\nTo be honest, I don’t get the reason for this rule. Why do you want to write empty statements? For me, both examples are just bad.<\/p>\n
\nfor<\/span> (i =<\/span> 0<\/span>; i <<\/span> max; ++<\/span>i); \/\/ BAD: the empty statement is easily overlooked<\/span>\r\nv[i] =<\/span> f(v[i]);\r\n\r\nfor<\/span> (auto<\/span> x :<\/span> v) { \/\/ better<\/span>\r\n \/\/ nothing<\/span>\r\n}\r\nv[i] =<\/span> f(v[i]);\r\n<\/pre>\n<\/div>\n <\/p>\n<\/p>\n
<\/span>ES.86: Avoid modifying loop control variables inside the body of raw for-loops<\/a><\/span><\/h3>\nOk. That is, from two perspectives, very bad practice. First, you should avoid writing raw loops and use the algorithms of the Standard Template Library. Second, you should not modify the control variable inside the for-loop. Here is the wrong practice. <\/p>\n
\nfor<\/span> (int<\/span> i =<\/span> 0<\/span>; i <<\/span> 10<\/span>; ++<\/span>i) {\r\n \/\/<\/span>\r\n if<\/span> (\/* something *\/<\/span>) ++<\/span>i; \/\/ BAD<\/span>\r\n \/\/<\/span>\r\n}\r\n\r\nbool<\/span> skip =<\/span> false<\/span>;\r\nfor<\/span> (int<\/span> i =<\/span> 0<\/span>; i <<\/span> 10<\/span>; ++<\/span>i) {\r\n if<\/span> (skip) { skip =<\/span> false<\/span>; continue<\/span>; }\r\n \/\/<\/span>\r\n if<\/span> (\/* something *\/<\/span>) skip =<\/span> true<\/span>; \/\/ Better: using two variable for two concepts.<\/span>\r\n \/\/<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
What makes it difficult for me to reason in particular about the second for-loop is that these are under the hood two nested dependent loops. <\/p>\n
<\/span>ES.87: Don\u2019t add redundant ==<\/code> or !=<\/code> to conditions<\/a><\/span><\/h3>\n I’m guilty. In my first years as a professional C++ developer, I often used redundant ==<\/span> or !=<\/span> in conditions. Of course, this changed in the meantime.<\/p>\n\n\/\/ p is not a nullptr<\/span>\r\nif<\/span> (p) { ... } \/\/ good<\/span>\r\nif<\/span> (p !=<\/span> nullptr) { ... } \/\/ redundant <\/span>\r\n\r\n\/\/ p is a nullptr<\/span>\r\nif<\/span> (!<\/span>p) { ... } \/\/ good<\/span>\r\nif<\/span> (p ==<\/span> 0<\/span>) { ... } \/\/ redundant <\/span>\r\n\r\nfor<\/span> (string s; cin >><\/span> s;) \/\/ the istream operator returns bool<\/span>\r\nv.push_back(s);\r\n<\/pre>\n<\/div>\n <\/p>\n
These were the rules to statements. Let’s continue with the arithmetic rules. Here are the first seven.<\/p>\n
\n- ES.100: Don\u2019t mix signed and unsigned arithmetic<\/a><\/li>\n
- ES.101: Use unsigned types for bit manipulation<\/a><\/li>\n
- ES.102: Use signed types for arithmetic<\/a><\/li>\n
- ES.103: Don\u2019t overflow<\/a><\/li>\n
- <\/a>ES.104: Don\u2019t underflow<\/a><\/li>\n
- <\/a>ES.105: Don\u2019t divide by zero<\/a><\/li>\n
- ES.106: Don\u2019t try to avoid negative values by using <\/span>
unsigned<\/code><\/a><\/li>\n<\/ul>\nHonestly, there is often not much for me to add to these rules. For completeness (and importance), I will briefly present the rules.<\/p>\n
<\/span>ES.100: Don\u2019t mix signed and unsigned arithmetic<\/a><\/span><\/h3>\nYou will not get the expected result if you mix signed and unsigned arithmetic. <\/p>\n
\n#include <iostream><\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n\r\n int<\/span> x =<\/span> -<\/span>3<\/span>;\r\n unsigned<\/span> int<\/span> y =<\/span> 7<\/span>;\r\n\r\n std::<\/span>cout <<<\/span> x -<\/span> y <<<\/span> std::<\/span>endl; \/\/ 4294967286<\/span>\r\n std::<\/span>cout <<<\/span> x +<\/span> y <<<\/span> std::<\/span>endl; \/\/ 4<\/span>\r\n std::<\/span>cout <<<\/span> x *<\/span> y <<<\/span> std::<\/span>endl; \/\/ 4294967275<\/span>\r\n std::<\/span>cout <<<\/span> x \/<\/span> y <<<\/span> std::<\/span>endl; \/\/ 613566756<\/span>\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
GCC, Clang, and Microsoft Compiler produced the same results.<\/p>\n
<\/span>ES.101: Use unsigned types for bit manipulation<\/a><\/span><\/h3>\nThe reason for the rules is quite simple. Bitwise operations on signed types are implementation-defined. <\/p>\n
<\/span>ES.102: Use signed types for arithmetic<\/a><\/span><\/h3>\nFirst, you should do arithmetic with signed types. Second, you should not mix signed and unsigned arithmetic. If not, the results may surprise you.<\/p>\n
<\/p>\n
\n#include <iostream><\/span>\r\n\r\ntemplate<\/span><<\/span>typename<\/span> T, typename<\/span> T2><\/span>\r\nT subtract(T x, T2 y){\r\n return<\/span> x -<\/span> y;\r\n}\r\n\r\nint<\/span> main(){\r\n \r\n int<\/span> s =<\/span> 5<\/span>;\r\n unsigned<\/span> int<\/span> us =<\/span> 5<\/span>;\r\n std::<\/span>cout <<<\/span> subtract(s, 7<\/span>) <<<\/span> '\\n'<\/span>; \/\/ -2<\/span>\r\n std::<\/span>cout <<<\/span> subtract(us, 7u<\/span>) <<<\/span> '\\n'<\/span>; \/\/ 4294967294<\/span>\r\n std::<\/span>cout <<<\/span> subtract(s, 7u<\/span>) <<<\/span> '\\n'<\/span>; \/\/ -2<\/span>\r\n std::<\/span>cout <<<\/span> subtract(us, 7<\/span>) <<<\/span> '\\n'<\/span>; \/\/ 4294967294<\/span>\r\n std::<\/span>cout <<<\/span> subtract(s, us +<\/span> 2<\/span>) <<<\/span> '\\n'<\/span>; \/\/ -2<\/span>\r\n std::<\/span>cout <<<\/span> subtract(us, s +<\/span> 2<\/span>) <<<\/span> '\\n'<\/span>; \/\/ 4294967294<\/span>\r\n\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
<\/span>ES.103: Don\u2019t overflow<\/a>, and ES.104: Don\u2019t underflow<\/a><\/span><\/h3>\nLet me combine both rules. The effect of an overflow or an underflow is the same: memory corruption and undefined behavior. Let’s make a simple test with an int<\/span> array. How long will the following program run?<\/p>\n\n\/\/ overUnderflow.cpp<\/span>\r\n\r\n#include <cstddef><\/span>\r\n#include <iostream><\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n int<\/span> a[0<\/span>];\r\n int<\/span> n{};\r\n\r\n while<\/span> (true<\/span>){\r\n if<\/span> (!<\/span>(n