Reboot

There was once a blog about a series of tales, memories gathered during a never-ending journey of C++ development, a recollection of advice helpful to those navigating these wild lands. The whispers went quieter, and for a while no more tales where heard... It’s once again an exciting time for C++, and with that the whispers awakened and got louder one more time. And so, I decided it was the right time to reboot that blog; time to record new tales but also to review the ones already told.

Continue the reboot of the blog here:  Tales of C++

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: