Today, 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.
Four rules to statements are left. Here are they:
The first rule is quite obvious.
Declaring a local variable without a name has no effect. With the final semicolon, the variable will go out of scope.
void f()
{
lock<mutex>{mx}; // Bad
// critical region
}
Typically, the optimiser can remove the creation of a temporary, if it will not change the observable behaviour of the program. This is the socalled asif rule. To put is the other way around. If the constructor has observable behaviour such as modifying the global state of the program, the optimiser is not allowed to remove the creation of the temporary.
To 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.
for (i = 0; i < max; ++i); // BAD: the empty statement is easily overlooked
v[i] = f(v[i]);
for (auto x : v) { // better
// nothing
}
v[i] = f(v[i]);
Ok. That is from two perspectives really a very bad practice. First, you should avoid to write raw loops and use the algorithms of the Standard Template Library. Second, you should not modify the control variable inside the forloop. Here is the bad practice.
for (int i = 0; i < 10; ++i) {
//
if (/* something */) ++i; // BAD
//
}
bool skip = false;
for (int i = 0; i < 10; ++i) {
if (skip) { skip = false; continue; }
//
if (/* something */) skip = true; // Better: using two variable for two concepts.
//
}
What makes it difficult for me to reason in particular about the second forloop is that this are under the hood two nested dependent loops.
I'm guilty. In my first years as professional C++ developer I often used redundant == or != in conditions. Of course, this changed in the meantime.
// p is not a nullptr
if (p) { ... } // good
if (p != nullptr) { ... } // redundant
// p is a nullptr
if (!p) { ... } // good
if (p == 0) { ... } // redundant
for (string s; cin >> s;) // the istream operator returns bool
v.push_back(s);
These were the rules to statements. Let's continue with the arithmetic rules. Here are the first seven.
Honestly, there is often not so much for me to add to this rules. For the sake of completeness (and importance), I will briefly present the rules.
If you mix signed and unsigned arithmetic, you will not get the expected result.
#include <iostream>
int main(){
int x = 3;
unsigned int y = 7;
std::cout << x  y << std::endl; // 4294967286
std::cout << x + y << std::endl; // 4
std::cout << x * y << std::endl; // 4294967275
std::cout << x / y << std::endl; // 613566756
}
GCC, Clang, and the Microsoft Compiler produced the same results.
The reason for the rules is quite simple. Bitwise operations on signed types are implementationdefined.
First, you should make arithmetic with signed types. Second, you should not mix signed and unsigned arithmetic. If not, the results may surprise you.
#include <iostream>
template<typename T, typename T2>
T subtract(T x, T2 y){
return x  y;
}
int main(){
int s = 5;
unsigned int us = 5;
std::cout << subtract(s, 7) << '\n'; // 2
std::cout << subtract(us, 7u) << '\n'; // 4294967294
std::cout << subtract(s, 7u) << '\n'; // 2
std::cout << subtract(us, 7) << '\n'; // 4294967294
std::cout << subtract(s, us + 2) << '\n'; // 2
std::cout << subtract(us, s + 2) << '\n'; // 4294967294
}
Let me combine both rules. The effect of an overflow or an underflow is the same: memory corruption and undefined behaviour. Let's make a simple test with an int array. How long will the following program run?
// overUnderflow.cpp
#include <cstddef>
#include <iostream>
int main(){
int a[0];
int n{};
while (true){
if (!(n % 100)){
std::cout << "a[" << n << "] = " << a[n] << ", a[" << n << "] = " << a[n] << "\n";
}
a[n] = n;
a[n] = n;
++n;
}
}
Disturbing long. The program writes each 100th array entry to std::cout.
If you want to have a crash you should divide by zero. Diving by zero may be fine in a logical expression.
bool res = false and (1/0);
Because the result of the expression (1/0) is not necessary for the overall result, it will not be evaluated. This technique is called short circuit evaluation and is a special case of lazy evaluation.
Don't use an unsigned type if you want to avoid negative values. The consequences may be serious. The behaviour of arithmetic will change and you are open to errors including signed/unsigned arithmetic.
Here are two examples of the Guidelines, intermixing signed/unsigned arithmetic.
unsigned int u1 = 2; // Valid: the value of u1 is 4294967294
int i1 = 2;
unsigned int u2 = i1; // Valid: the value of u2 is 4294967294
int i2 = u2; // Valid: the value of i2 is 2
unsigned area(unsigned height, unsigned width) { return height*width; }
// ...
int height;
cin >> height;
auto a = area(height, 2); // if the input is 2 a becomes 4294967292
As the Guidelines stated there is an interesting relation. When you assign a 1 to an unsigned int, you will become the largest unsigned int.
Now to the more interesting case. The behaviour of arithmetic will differ between signed and unsigned types.
Let's start with a simple program.
// modulo.cpp
#include <cstddef>
#include <iostream>
int main(){
std::cout << std::endl;
unsigned int max{100000};
unsigned short x{0}; // (2)
std::size_t count{0};
while (x < max && count < 20){
std::cout << x << " ";
x += 10000; // (1)
++count;
}
std::cout << "\n\n";
}
The key point of the program is that the successive addition to x in line (1) will not trigger an overflow but a modulo operation if the value range of x ends. The reason is that x is of type unsigned short (2).
// overflow.cpp
#include <cstddef>
#include <iostream>
int main(){
std::cout << std::endl;
int max{100000};
short x{0}; // (2)
std::size_t count{0};
while (x < max && count < 20){
std::cout << x << " ";
x += 10000; // (1)
++count;
}
std::cout << "\n\n";
}
I made a small change to the program modulo.cpp such that x (2) becomes a signed type. The same addition will now trigger an overflow.
I marked the key points with red circles in the screenshot.
Now, I have a burning question: How can I detect an overflow? Quite easy. Replace the erroneous assignment x += 1000; with an expression using curly braces: x = {x + 1000};. The difference is that the compiler checks narrowing conversions and, therefore, detects the overflow. Here is the output from GCC.
Sure the expressions (x += 1000) and (x = {x + 1000}) are from a performance perspective not the same. The second one could create a temporary for x + 1000. But in this case, the optimiser did a great job and both expressions were under the hood the same.
What's next?
I'm nearly done with the arithmetic rules. This means in the next post I will continue my journey with the rules to performance.
Thanks a lot to my Patreon Supporters: Eric Pederson, Paul Baxter, Carlos Gomes Martinho, and SAI RAGHAVENDRA PRASAD POOSA.
Get your ebook at leanpub:
The C++ Standard Library


Concurrency With Modern C++


Get Both as one Bundle






With C++11, C++14, and C++17 we got a lot of new C++ libraries. In addition, the existing ones are greatly improved. The key idea of my book is to give you the necessary information to the current C++ libraries in about 200 pages. 

C++11 is the first C++ standard that deals with concurrency. The story goes on with C++17 and will continue with C++20.
I'll give you a detailed insight in the current and the upcoming concurrency in C++. This insight includes the theory and a lot of practice with more the 100 source files.


Get my books "The C++ Standard Library" (including C++17) and "Concurrency with Modern C++" in a bundle.
In sum, you get more than 550 pages full of modern C++ and more than 100 source files presenting concurrency in practice.

Read more...