This post is part of a collaboration with Arne Mertz. Arne is a software Engineer at Zühlke and a clean code enthusiast with a focus on modern C++. You can find him online at Twitter and at his “Simplify C++!” blog. We’ve both written something about accessing std::tuple, but swapped our blogs - my post is over at his blog and his one follows here now:

Did you ever wonder how we could iterate over the contents of a std::tuple at runtime, similar to an array or std::vector? You may or may not see the need for such a functionality - this walkthrough shows a proof of concept and how you tackle problems like this in C++17.

Policy-based design is a great way for library authors to provide more flexibility to the user. Instead of hard coding certain behaviors, policy-based design provides various policies the users can select to customize the behavior. If done properly, a library author can accommodate all use cases with a single implementation.

I’m a big fan of policy-based design for that reason. Whenever there’s a possible trade-off, where multiple solutions are possible, each with their own set of advantages and disadvantages, I make the decision available to the user. Instead of favoring a certain use case, I favor all of them. This is for example what I did with my variant implementation.

However, policy-based design isn’t perfect. In particular, it has a great problem: It creates lots and lots of different and incompatible types.

I’ve recently read this blog post by Vittorio Romeo. He talks about various ways to pass a function (callback, comparator for algorithm, etc.) to another function. One of them is function_view. function_view is a lightweight std::function: it should be able to refer to any callable with a given signature. But unlike std::function it does not own the callable, just refers to it. This allows a much more efficient implementation.

In this post he presented one. But his has a flaw, that can bite you very easily.

While browsing the C++ subreddit I’ve encountered the following comment.

I’m not going to jump on the exception discussion currently happening in the child comments. I’m just going to focus on the part where he said it is sad that C++ constructors require exceptions for error handling. So let’s assume you don’t have exception support in your application and has a constructor that needs to report an error. What do you do?

C++17 is going to add std::variant. To quote the linked documentation, it is a “type-safe union”. A union is like a struct, but can only store one member at a time. This has many applications, but sadly it doesn’t mix well with non-trivial types, you have to call the destructor yourself etc. Furthermore, nothing prevents you from accessing a union member that isn’t active.

std::variant fixes that. It correctly calls the destructor when switching the active member, it prevents invalid access, etc. However, I’m not quite happy with it and I needed an implementation now. So I’ve decided to implement my own variant as part of my type_safe library.

It was a fun challenge and since my previous attempt was two years ago, I could improve it a lot. Let’s go through some of my design decisions.