Episode Eleven: Exceptions for the Exceptional

An exception breaks the normal flow of code under given conditions, and forces the caller to deal with them, as opposed to return codes. In C++, exceptions should be used for the exceptional situations only. An exceptional situation is something that should never happen (yet it might). This is not the situation with other languages; notably Python throws an exception to signal the end of an iteration.

Episode Ten: The Natural Order of Things

While each statement is evaluated after the previous one, the evaluation of individual sub-expressions is left unspecified in C++. This is supposed to allow producing optimal code for the target platform, as opposed to intuitive left-to-right evaluation everywhere. Code relying on the implementation defined evaluation order is thus non-portable. This means that `v[i] = i++`, `v[i] + i++` and even `f(v[i], i++)` are all examples of non-portable code. Generally speaking, when a variable is read twice and also written in the same expression the result is undefined.

The standard defines a few exceptions where evaluation order is specified:

Episode Nine: Erasing the Concrete

Type erasure is a technique that allows to store and operate objects of different types that fulfill a given concept. It can be seen as non-intrusively introducing an abstract base class to every type that provides a common interface. It turns a wide variety of types into one type.

Two big exponents of type erasure are Boost.Any [1] and Boost.Function [2]. Boost.Any is like C# and Java's Object base class, except it has value semantics. Boost.Function implements a generalized callback type that can be used to store arbitrary function pointers and function objects.

Episode Eight: The Curious Case of Recurring Template Pattern

The curiously recurring template pattern (CRTP) is an idiom in which a class X derives from a class template instantiation using X itself as template argument. It splits generic and concrete functionality by delegating to its derived class. This works because X is an incomplete type at the point of template instantiation, and it only works when the declaration of the base template does not use X as a complete type. Member function definitions, on the other side, are instantiated long after their declarations, allowing use of members of the derived class via the use of a static_cast.

Episode Seven: One char to Rule Them All

There are three char types in C++: one is signed, one is unsigned, and the other one is neither of those. From the standard, 3.9.1.1:

Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.11); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation.

Episode Six: Boolsh*t

The built-in type bool is an integral type that can have one of the two values `true` or `false`. Despite being an integral type there are no signed, unsigned, short, or long bool types or values. There are some special situations where extra care is needed when working with bools:

Episode Five: Explicit is Better than Implicit

Type conversion allows one type to convert to another. In C++, they came in two flavours:

• Conversion by construction: Constructors that can be called with a single argument are called converting constructors. This includes constructors with a single formal argument, as well as constructors with more than one argument that specifies default values. Implements conversion-from-type, intrusive on the destination type.

• Conversion functions: Also called conversion operators, are member functions defined as `operator Type() [const]` (Note no result type defined). Implements conversion-to-type, intrusive on the source type.