Thoughts from a C++ library developer.

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:

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

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.

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.

Documentation is essential.
Without knowing what certain functions/classes/… do, it is very difficult to use any code properly.

Tools can help to provide a documentation.
They can extract information from the source code and combine it with manually written information to generate documentation in a human readable output format.

There is a problem though: The current tools for C++ documentation aren’t that great.
This post explains why and provides a (work-in-progress) solution.

The last posts showed low-level techniques like ensuring inlining or removing branches.

But those techniques alone were not sufficient.

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned in the process of beating Boost.Pool.
The final post shows how to apply those techniques when designing your abstractions and the importance of smart algorithms.