08 - operators

Overflow

If the result of the operation can not be represented (e.g. multiplication of 2 large integers produced value that does not fit in range)

• for signed integers: the behavior is undefined

• for unsigned integers: the value wraps around

Previously it was said that operations on signed and unsigned integers can be done using the same circuit - and this is still true for most hardware. C++ defines them differently though.

When overflow happens, the value wraps around. A good analogy is an odometer or a clock. The set of possible values is finite and there is a continuity between lowest and highest value.

During overflow, the most significant digit is lost. In binary system, the wrapping happens at powers of 2 - for an 8-bit integer adding 1 to 1111 1111 (255) would make it 1 0000 0000 so after discarding excess digit, it becomes 0000 0000 (0).

• For unsigned integers, this behavior is very desirable. Various formulas intentionally use wrapping behavior to form cycles or some pattern of repetition in output. Cryptography, hashing, control checksums and compression are very prominent users of overflow wrapping.

• For signed integers, the behavior has no good use because the lowest representatable value is not zero, but some negative number. So instead of starting over from zero, it starts over from some huge negative value. Such behavior has no practical use. Even worse, it's a very good source of bugs, most commonly found in games. If players find an overflow bug within a tycoon-style game, they can try to form a construction so expensive that its total cost overflows, which then causes the cost to be negative which then causes the game to subtract negative amount of in-game currency from their inventory, effectively giving them money instead of spending it.

Undefined behavior gives the compiler infinite freedom for optimization. Since anything can happen, any machine code will be fine as long as other requirements are fulfilled. This lets compilers optimize away code like if (x + 1 < x) as the only situation in which the statement could be triggered is overflow. If x is a signed number, compiler can assume overflow never happens (programs should be free of undefined behavior) and remove dead code.

But who would write such nonsensical code?

It happens more often than you think. This example is very trivial, but once you start using more complex abstractions you will realize how easy it is to accidentally create such situations. The other thing is that you are still at the beginning of the tutorial so I can't really provide more complex examples.

You can see the difference on compiler explorer - functions are almost identical; the one operating on signed integer doesn't do any comparison in its machine code.

Overflow is reversible:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <iostream>
#include <cstdint> // for fixed-width type aliases

int main()
{
	std::uint16_t x = 65535u;
	std::cout << "before overflow: " << x << "\n";

	x += 3;
	std::cout << "after overflow: " << x << "\n";

	x -= 3;
	std::cout << "after another overflow: " << x << "\n";
}

Summing it up:

• Overflow on unsigned numbers is well-defined in C++ because underlying hardware behavior is useful.

• Overflow on signed numbers is undefined in C++ because it's not useful and making it undefined gives more freedom for optimizations.

...and for this reason:

Underflow

First, some clarity as this term often gets misunderstood. There is a common mistake where going below minimum representatable value is referred to as underflow.

Underflow occurs when the value is so small that the closest representatable value is zero. The following program continuously divides the same variable untill its value underflows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <iostream>

int main()
{
	auto x = 1.0f;

	while (x != 0)
	{
		std::cout << x << "\n";
		x /= 2.0f;
	}

	std::cout << x << "\n";
}

More floating point shenanigans

If you are really interested about floating-point, I recommend you to watch CppCon 2015: John Farrier - Demystifying Floating Point. The presentation goes over many peculiarities and gives insight into various solutions. Knowing these is what separates good programmers from the best programmers.

Short summary of key points in the presentation:

• Normalize values to range -1 - 1. Calculations in this range have highest precision.

• Use formulas which don't mix big numbers with small numbers. Separate big with big and small with small operations will achieve more accurate results.

• Don't ever compare floating-point directly as their equality (except with zero) is basically unachieveable. Instead, make comparisons within +/- epsilon tolerance from expected result.

• There are multiple ways to round floating-point numbers:

  • towards zero

  • towards nearest integer

  • towards positive infinity

  • towards negative infinity

• If you aren't sure, prefer multiplication over division (x / y can be refactored to x * (1 / y)). It's usually more precise and faster.

• Avoid accumulation of bias: instead of adding a floating-point constant after every iteration, count number of iterations (as integer) and multiply it with the constant.

• Check how your hardware treats denormal numbers. Some may feature 100x slowdown in which case you might prefer to change settings to perform underflow.

Precedence

Some operators have higher priority than others. Because C++ has over 40 different operators, no one remembers their precedence perfectly - only some of them are strictly related to math. Things can get complicated once multiple very different operators are used in one expression.

Therefore, it's highly recommended to wrap complex subexpressions in parentheses:

1
2

 a +   b * c  % d   ^  e & f  // unclear order unless reader remembers rules perfectly
(a + ((b * c) % d)) ^ (e & f) // much cleaner

This will make reading code easier while also saving you some time from dealing with unexpected bugs.

Spacing

It's intuitive for unary operators to have higher priority than binary operators: x + !y is processed as x + (!y). While whitespace characters doesn't matter in this case, it's highly recommended to write spaces around binary operators and stick unary operators to their arguments.

1
2
3
4
5
6

// bad
a+!b +c [d] <<e
a + ! b + c[ d]<< e
a +! b+c [ d ] << e
// good
a + !b + c[d] << e

In other words, operators which are applied first should be closer to the object.