Episode Fifteen: What's In A Name?

In C++'s world, a rose by any other name may not smell as sweet. Names in C and C++ do not only identify things, but they can convey properties of such things. Consider the following declaration:

Episode Fourteen: Proper Closure

It's polite to include proper closing when writing letters or emails. C++ is actually stricter, and enforces proper file closing in standard compliant code. Unfortunately most -if not all- current compilers would humour nonstandard impolite code; some won't even issue a warning. As a result, portable yet nonstandard code gets away with it.

Episode Thirteen: The Ways Of sizeof

C++ inherits from C the sizeof operator; it yields the number of bytes in the object representation of its operand. It comes in two flavours, `sizeof( type-name )` and `sizeof expression`. It's important to note that expressions in the form `sizeof( ptr )->member` refer to the second sizeof form, and are not a syntactic error.

While sizeof is just about getting the size of its operand, its power extends beyond that.

Episode Twelve: When the Size *does* Matter

In C++, zero-sized addressable objects are forbidden. Objects must have size, even if they are empty. This is required in order to have different addresses for different objects. From the standard, 1.8.5:

A most derived object shall have a non-zero size and shall occupy one or more bytes of storage. Base class subobjects may have zero size.

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.