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.

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.

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.

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.

C++11 introduced the final “keyword”. It can be used to mark member functions and classes as final, meaning that they cannot be overridden in derived classes/be base classes.

In this post I’ll take a closer look and explain why I consider the use of final classes problematic in some cases.