![\"UnderConstruction\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/02\/UnderConstruction.png\")
<\/p>\nBefore I continue with the roughly 15 rules for statements, let me finish the two rules for expressions. Both rules help you to protect your program from undefined behavior. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Here are the two remaining rules for expressions.<\/p>\n
T{e}<\/code>notation for construction<\/a><\/h3>\nThe reason for using T{e}<\/span> to construct a value is quite apparent. In contrast to T(e) or (T)e, T{e}<\/span> does not allow narrowing conversion. Narrowing conversion is a conversion including the loss of data accuracy. I assume this is, most of the time, not your intention. Have a look at the example from the guidelines.<\/p>\n <\/p>\n
\nvoid<\/span> use<\/span>(char<\/span> ch, double<\/span> d, char<\/span>*<\/span> p, long<\/span> long<\/span> lng){\r\n int<\/span> x1 =<\/span> int<\/span>{ch}; \/\/ OK, but redundant<\/span>\r\n int<\/span> x2 =<\/span> int<\/span>{d}; \/\/ error: double->int narrowing; use a cast if you need to<\/span>\r\n int<\/span> x3 =<\/span> int<\/span>{p}; \/\/ error: pointer to->int; use a reinterpret_cast if you really need to<\/span>\r\n int<\/span> x4 =<\/span> int<\/span>{lng}; \/\/ error: long long->int narrowing; use a cast if you need to (1)<\/span>\r\n\r\n int<\/span> y1 =<\/span> int<\/span>(ch); \/\/ OK, but redundant<\/span>\r\n int<\/span> y2 =<\/span> int<\/span>(d); \/\/ bad: double->int narrowing; use a cast if you need to<\/span>\r\n int<\/span> y3 =<\/span> int<\/span>(p); \/\/ bad: pointer to->int; use a reinterpret_cast if you really need to (2)<\/span>\r\n int<\/span> y4 =<\/span> int<\/span>(lng); \/\/ bad: long->int narrowing; use a cast if you need to<\/span>\r\n\r\n int<\/span> z1 =<\/span> (int<\/span>)ch; \/\/ OK, but redundant<\/span>\r\n int<\/span> z2 =<\/span> (int<\/span>)d; \/\/ bad: double->int narrowing; use a cast if you need to<\/span>\r\n int<\/span> z3 =<\/span> (int<\/span>)p; \/\/ bad: pointer to->int; use a reinterpret_cast if you really need to (3)<\/span>\r\n int<\/span> z4 =<\/span> (int<\/span>)lng; \/\/ bad: long long->int narrowing; use a cast if you need to <\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Here is what Gcc provides without any special flags.<\/p>\n
![\"Screenshot](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/02\/Screenshot_20180223_192512.png\")
<\/p>\n
If you carefully read the output of the compiler run, you will observe a few interesting facts.<\/p>\n
\n- Expression (1) will only give a warning in the first code block; the two previous expressions will produce an error.<\/li>\n
- Only the expressions (2) and (3) result in an error. The other conversions in the second and third code block will not even give a warning.<\/li>\n<\/ul>\n
You must keep a particular rule in mind if you construct a value with T(e1, e2)<\/span> or T{e1, e2}<\/span>. What will happen if you have a class that has two competing constructors? One constructor accepting two ints (MyVector(int, int))<\/span> and the other accepting an std::initializer_list<int> (MyVector(std::initializer_list<int>))? T<\/span>he interesting question is: Does a call MyVector(1, 2)<\/span> or a call MyVector{int, int}<\/span> the constructor for two ints or the one with the std::initalizer_list<int><\/span>?<\/p>\n <\/p>\n
\n\/\/ constructionWithBraces.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nclass<\/span> MyVector<\/span>{\r\npublic:<\/span>\r\n MyVector(int<\/span>, int<\/span>){\r\n std::<\/span>cout <<<\/span> \"MyVector(int, int)\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n MyVector(std::<\/span>initializer_list<<\/span>int<\/span>><\/span>){\r\n std::<\/span>cout <<<\/span> \"MyVector(std::initalizer_list<int>)\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n};\r\n\r\nclass<\/span> MyVector1<\/span>{\r\npublic:<\/span>\r\n MyVector1(int<\/span>, int<\/span>){\r\n std::<\/span>cout <<<\/span> \"MyVector1(int, int)\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n};\r\n\r\nclass<\/span> MyVector2<\/span>{\r\npublic:<\/span>\r\n MyVector2(int<\/span>, int<\/span>){\r\n std::<\/span>cout <<<\/span> \"MyVector2(int, int)\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n MyVector(1<\/span>, 2<\/span>); \/\/ (1)<\/span>\r\n MyVector{1<\/span>, 2<\/span>}; \/\/ (2) <\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n MyVector1{1<\/span>, 2<\/span>}; \/\/ (3)<\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n MyVector2(1<\/span>, 2<\/span>); \/\/ (4)<\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
<\/p>\n
Here is the output of the program. The call (1) calls the constructor with two ints; the call (2) the constructor with the std::initializer_list<int><\/span>. If you invoke MyVector1{1, 2}<\/span> (3), der constructor MyVector1(1, 2)<\/span> is a kind of fallback.<\/p>\nThey will not hold for (4). In this case, the constructor with the std::initializer_list<int><\/span> is not the fallback. <\/p>\n <\/p>\n
![\"constructionWithBracesError\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/02\/constructionWithBracesError.png\")
<\/p>\n
A constructor taking a std::initializer_list<\/span> as an argument is often called a sequence constructor. <\/p>\nDo you know why I called the class in the example MyVector<\/span>? The reason is that the two following expressions behave differently.<\/p>\n <\/p>\n
\nstd::<\/span>vector<<\/span>int<\/span>><\/span> vec(10<\/span>, 1<\/span>); \/\/ ten elements with 1<\/span>\r\nstd::<\/span>vector<<\/span>int<\/span>><\/span> vec2{10<\/span>, 1<\/span>}; \/\/ two elements 10 and 1<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
The first line creates a vector of 10 elements with the value 1; the second line will create a vector with the values 10 and 1.<\/p>\n<\/p>\n
ES.65: Don\u2019t dereference an invalid pointer<\/a><\/h3>\nLet me put it this way. If you dereference an invalid pointer, such as a nullptr<\/span>, your program has undefined behavior. This is nasty. The only way to avoid this is to check your pointer before its usage.<\/p>\n\nvoid<\/span> func<\/span>(int<\/span>*<\/span> p) {\r\n if<\/span> (p ==<\/span> nullptr) { \/\/ do something special<\/span>\r\n }\r\n int<\/span> x =<\/span> *<\/span>p;\r\n ...\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
How can you overcome this issue? Don’t use a naked pointer. Use a smart pointer such as std::unique_ptr<\/span> or std::shared_ptr<\/span> or a reference. I have already written a post on the different kinds of ownership semantics in modern C++. Read the details here: C++ Core Guidelines: Rules to Resource Management.<\/a><\/p>\nLet’s switch gears. <\/p>\n
Rule for statements<\/h2>\n
The statement rules are pretty obvious; therefore, I can make it short.<\/p>\n
\n- It will help if you prefer a switch s<\/span>tatement to an if <\/span>statement when there is a choice (ES.70) <\/a>because a switch <\/span>statement may be more readable and can be better optimized.<\/li>\n
- The same holds for a range-based for-loop (ES.71<\/a>) compared to a for-loop. First, a range-based for loop is easier to read, and second, you can not make an index error or change the index while looping.<\/li>\n
- When you have an obvious loop variable, you should use a for-loop instead of a while statement<\/span> (ES.72<\/a>); if not, you should use a while statement<\/span> (ES.73<\/a>).<\/li>\n<\/ul>\n
(1) shows an example of when you should prefer a for loop and (2) when you should prefer a while statement<\/span>.<\/p>\n <\/p>\n
\nfor<\/span> (gsl::<\/span>index i =<\/span> 0<\/span>; i <<\/span> vec.size(); i++<\/span>) { \/\/ (1)<\/span>\r\n \/\/ do work<\/span>\r\n}\r\n\r\nint<\/span> events =<\/span> 0<\/span>; \/\/ (2)<\/span>\r\nwhile<\/span> (wait_for_event()) { \r\n ++<\/span>events;\r\n \/\/ ...<\/span>\r\n}<\/pre>\n<\/div>\n <\/p>\n
\n- You should declare a loop variable in a for-loop (ES.74). <\/a>This will hold for a for-loop and since C++17 for an if<\/span>– or switch<\/span>-statement. Read the details here: C++17 – What’s new in the core language?<\/a><\/li>\n
- Avoid do<\/span>-statements (ES.75<\/a>) and goto<\/span>-statements (ES.76<\/a>), and minimize the use of break<\/span> and continue<\/span> in loops (ES.77<\/a>) because they are difficult to read. If something is difficult to read, it’s also error-prone.<\/li>\n<\/ul>\n
What’s next?<\/h2>\n