Little wonders of C++ (3)

C++ is transforming into a better language, that is even more powerful than before and much easier and robust to write.

In this part we will focus on a few things that have been promised in the last two parts. In the beginning we will therefore look at customizing literals.

Custom literal suffixes

In the previous part I introduced (new) string literals. In the presentation I also mentioned the upcoming suffix s to immediately transform a string (const char*) literal to a std::string (basically wrapping the literal in a constructor call).

This is certainly a big step forward, as good C++ code generally tends to use std::string over the (raw) C variant. Reasons for this are multiple. Most importantly allocation and de-allocation of the char* are determined. Also the standard variant also uses the move constructor, basically allowing us to write fast performing, elegant code with ease.

But wait a second. C++ let's us define our own suffix operators (since C++11). So, as long as our compiler is ready, we can just define such a suffix in our code and we are good. There is just one constraint: Our own suffix operators have to start with an underscore (_). This has been introduced to reduce the chance of code breaking later on, as more suffix operators defined by the standard committee will enter sooner or later.

One should, however, due to readability use these operators with care.

Compile time constants with constexpr

Compile-time constants are essential for optimizations. If such constants are placed in the right order, the compiler can do some (trivial) calculations, which then don't need to be done. For us programmers this is handy, as "magic" numbers may therefore need less explanations in form of comments. One just defines a few (well-named) constants, and plugs in the computation. The compiler already performs the computation, which means that we do not have to manually compute the result.

Even better are compile-time constant functions. These functions may operate directly during compile-time, if the arguments are compile-time constants. If the arguments are not compile-time constants, the function is called at runtime. Nevertheless, this is not guaranteed. What is important is the possibility of running the function during compile-time. This can therefore save function calls during runtime, drastically increasing performance.

Now it would be great to just decorate all functions as constexpr. However, this is not possible. Functions that can be decorated as constexpr must fulfill certain requirements. In simple words: they have to be trivial enough to guarantee that the compiler is not running longer than the actual program would be. This constraint basically reduces such functions to use only other constexpr variables and functions. Also only simple types can be used for the data.

While const for a variable could result in similar behavior, constexpr now guarantees us evaluation during compile-time.

The best thing with constexpr is that this pretty much replaces (at least one) usage of C macros: Having a defined way of compile-time constants. No more macro magic and more power in the language itself.

Supporting initializer lists

C++ added support for initializer list a long time ago. With initializer lists one could for instance not only allocate a vector with a certain size, but already fill the vector. We already talked about the uniform construction in the last part, which is why I skip the basic syntax in this one.

What is important is to realize that previously there was no way of telling C++ how to use the initializer list. Either C++ knew how to use it for a certain type (e.g., a classic C (or even C++) array, or for instance std::vector<T>), or we have not been able to make use of the initializer list.

With C++11 this changed. Now the following works:

MyCollection<int> array { 2, 4, 8, 11, 15 };

How it this possible? It basically works once we setup a compile to make use of the initializer list. Let's see an example for the code above:

All we need is a constructor that supports std::initializer_list<T> as single argument. Once we provide such a constructor, it always is preferred to other constructors. This will have consequences, however, usually we only write such a constructor if we really want this behavior.

It should be noted that using std::initializer_list<T> is not limited to constructors. We can also write methods that support this type as argument.

Iterators

Iterators are quite mighty. We already know them quite well from languages such as Java or C#. There an iterator is usually any class that implements a specific interface. Java named this interface Iterable<T>. This one will basically introduce a method to return an Iterator<T>. C# follows this pattern by having IEnumerable<T> and IEnumerator<T> interfaces to represent pretty much the same thing.

But iterators exist in C++ for a long time. They are standardized and usually come from calling a begin() or end() method. The simplest form of an iterator is a pointer.

An iterator in C++ just requires an operation such as the increment (and / or decrement) to be implemented. Also the de-referencing operator has to be implemented. All these operations exist trivially on a pointer object.

The previous example will iterate through all the values in the dynamic array numbers. We use the begin() method to get a fine starting point and check if we have already reached the end by comparing with the result of calling the end() method.

To quote Alex Allain: "The concept of an iterator is fundamental to understanding the C++ Standard Template Library (STL) because iterators provide a means for accessing data stored in container classes such a vector, map, list, etc.". It is also crucial for the next point.

Range based loops

Now that we introduced iterators we want to get rid of the clumsy (but highly useful) syntax in the previous example. The for-loop is really lengthy and one can easily understand, that such a useful pattern is used all over the place. Clumsy code everywhere!

Not with C++11! Here we have a great way out: The range based for loop. This construct is similar to foreach in C# and looks more like the range based for loop in Java. In both languages the range based loop works with classes that implement an interface to return an iterator (e.g. an IEnumerator<T> instance), i.e. that implement, e.g., IEnumerable<T> in C#.

What is not known for most people that program C#: The foreach construct does not rely on the interface being implemented. It actually only cares about the functions (usually forced to be implemented by the interface) being available. This is known as duck typing. If it behaves like something that can be iterated, it must be an iterator.

C++ also follows this path. Even worse (somehow), there is no (at least at the moment) class / interface to force certain methods to be implemented. Nevertheless, the only two things we require are begin() and end() methods that return valid iterators.

If a const type is used, the const version of begin() / end() will be used. In this case, they are not available, so the compiler cannot use these. In general we should also provide such methods, resulting in 4 (instead of 2) additional methods.