Move safety - know what can be done in the moved-from state

C++ programmers have this notion of exception safety. It is a very useful concept. With it one can easily describe the post-conditions of a function if it throws.

There is another situation where you need to easily describe some post-conditions: when talking about the state of an object after a move operation, i.e. after a move constructor or move assignment operator. I thus want to introduce vocabulary for those post-conditions of the right-hand argument similar to the exception safety of a function: The move safety, if you will.

The exception safety describes the post-conditions of a function if the function throws an exception. Similarly, the move safety describes the post-conditions of the object after a move operation. It thus gives information about what can be done safely with a moved-from object.

» read more »
Author's profile picture Jonathan

Tutorial: Easy dependency management for C++ with CMake and Git

C++ dependency management is a more controversial topic with many alternatives and lots of third-party tools. The following reddit comment describes it well:

This tutorial explains a relatively simple solution using CMake - the de-facto standard build tool - and git - the de-facto source code version control system. It doesn’t require any external tools, works on all platforms and is relatively easy to setup and flexible for the user. This is the same system I’m currently using for standardese, my C++ documentation generator.

» read more »
Author's profile picture Jonathan

Flexible error handling techniques in C++

Sometimes things aren’t working. The user enters stuff in the wrong format, a file isn’t found, a network connection fails and the system runs out of memory. Those are errors and they need to be handling.

In a high-level function this is relatively easy. You know exactly why something was wrong and can handle it in the right way. But for low-level functions this isn’t quite as easy. They don’t know what was wrong, they only know that something was wrong and need to report it to their caller.

In C++ there are two main strategies: error return codes and exceptions. The “modern”, mainstream C++ way of handling errors are exceptions. But some people cannot use/think they cannot use/don’t want exceptions - for whatever reason.

This blog post isn’t going to pick a side on the fight. Instead I am describing techniques that make both sides - relatively - happy. Those techniques are especially useful if you are developing libraries.

» read more »
Author's profile picture Jonathan

Standardese documentation generator version 0.1

A little over a month ago, I’ve released the first prototype of standardese. Now, it has finally reached version 0.1 - it took way longer than I thought.

Well, it always takes longer as the estimate.

It doesn’t bring many more features on first look, but massive parsing improvements.

» read more »
Author's profile picture Jonathan

You (probably) do want `final` classes?

In the previous post I’ve discussed the C++11 final keyword and how it can be used. I also gave a guideline that you shouldn’t use final on non-polymorphic classes. My reasoning was as follows:

  1. For some classes - like policy classes or any other class where you might want to have the EBO - making them final can be harmful.

  2. For other classes - those which aren’t used polymorphically - final is unnecessary. Every (good) C++ developer is taught early on that you shouldn’t use a class in a polymorphic inheritance hierarchy if it doesn’t have any virtual functions. Public inheritance there makes no sense and is harmful. Everybody knows that, the final is just there to enforce it.

  3. There are only little use cases for final in polymorphic hierarchies. So in general you don’t need it.

This has spawned a discussion both on reddit and in the blog comments, so I decided to write this follow-up to unify the discussion and write about each argument.

» read more »
Author's profile picture Jonathan