foonathan::blog()

Trip Report: Fall ISO C++ Meeting in Wrocław, Poland

Wed, 20 Nov 2024 00:00:00 +0000

Last week, I attended the fall 2024 meeting of the ISO C++ standardization committee in Wrocław, Poland. This was the fifth meeting for the upcoming C++26 standard and the feature freeze for major C++26 features. For an overview of all the papers that made progress, read Herb Sutter’s trip report. Contracts and profiles are the big ticket items that made the most progress this meeting. Contracts is forwarded to wording review, while still being fiercely opposed by some. Profiles is essentially standardized static analysis to improve memory safety, although some deem it ineffective. Due to various scheduling conflicts I did not attend any of the relevant discussions in these spaces. Instead, I am going to share my thoughts about ranges, relocation, and reflection.

if constexpr requires requires { requires }

Wed, 23 Oct 2024 00:00:00 +0000

Probably the two most useful features added to C++20 are requires and requires. They make it so much easier to control overload resolution, and when combined with if constexpr in C++17, they allow basic reflection-based optimizations in templates. While requires requires has gotten a lot of (negative?!) press for controlling overload resolution, its cousin requires { requires } is a bit overlooked.

Trip Report: Summer ISO C++ Meeting in St. Louis, USA

Fri, 12 Jul 2024 00:00:00 +0000

Two weeks ago, I attended the summer 2024 meeting of the ISO C++ standardization committee in St. Louis, USA. We made progress on a lot of features for C++26, but I have some thoughts about senders/receivers, reflection, and the idea of introducing borrow checking to C++.

Trip Report: C++Now 2024

Wed, 08 May 2024 00:00:00 +0000

Last week, I’ve attended C++Now 2024 and it was definitely one of the best conferences I’ve ever been to!

Trip Report: Spring ISO C++ Meeting in Tokyo, Japan

Wed, 27 Mar 2024 00:00:00 +0000

Last week, I attended the spring 2024 meeting of the ISO C++ standardization committee in Tokyo, Japan. We made progress on a bunch of interesting features for C++26.

I'm the new assistant chair of SG 9, the study group for std::ranges!

Fri, 08 Mar 2024 00:00:00 +0000

In a week, the C++ standardization committee is meeting in Tokyo, Japan, to continue work on C++26. It will be my first meeting with an official role as assistant chair of SG 9.

C++ needs undefined behavior, but maybe less

Mon, 20 Nov 2023 00:00:00 +0000

The C++ standard does not specify all behavior. Some things are up to the implementation, while other operations are completely undefined, and the compiler is free to do whatever it wants. This is essential for some optimizations but can also be dangerous. The newly proposed erroneous behavior addresses it, but it cannot be used to eliminate all undefined behavior.

Compile-time sizes for range adaptors

Tue, 29 Aug 2023 00:00:00 +0000

In my previous blog post, we’ve discussed the static constexpr std::integral_constant idiom to specify the size of a range at compile-time. Unlike the standard, our [think-cell’s] ranges library at think-cell already supports compile-time sizes natively, so I was eager to try the idiom there and see how it works out in practice.

namespace tc
{
    template <typename Rng>
    constexpr auto size(Rng&& rng); // runtime-size of a range, like std::ranges::size

    template <typename Rng> requires tc::has_constexpr_size<Rng>
    constexpr auto constexpr_size = …; // compile-time size of a range given its type
}

The new static constexpr std::integral_constant idiom

Mon, 07 Aug 2023 00:00:00 +0000

The size of std::array<T, N> is known at compile-time given the type. Yet it only provides a regular .size() member function:

template <typename T, std::size_t N>
struct array {
    constexpr std::size_t size() const {
        return N;
    }
};

This is annoying if you’re writing generic code that expects some sort of compile-time sized range.

Should we stop writing functions?

Tue, 25 Jul 2023 00:00:00 +0000

… and use lambdas instead?

That is, instead of:

int sum(int a, int b) {
    return a + b;
}

You’d write:

constexpr auto sum = [](int a, int b) -> int {
    return a + b;
};

Hear me out.

Constrain your user-defined conversions

Wed, 05 Jul 2023 00:00:00 +0000

Sometimes you want to add an implicit conversion to a type. This can be done by adding an implicit conversion operator. For example, std::string is implicitly convertible to std::string_view:

class string { // template omitted for simplicity
public:
    operator std::string_view() const noexcept
    {
       return std::string_view(c_str(), size());
    }
};

The conversion is safe, cheap, and std::string and std::string_view represent the same platonic value — we match Tony van Eerd’s criteria for implicit conversions and using implicit conversions is justified.

However, even when all criteria are fulfilled, the conversion can still be dangerous.

Trip report: Summer ISO C++ Meeting in Varna, Bulgaria

Sat, 10 Jun 2023 00:00:00 +0000

Last week, I attended the summer 2023 meeting of the ISO C++ standardization committee in Varna, Bulgaria. This was my first meeting since the pandemic and the first meeting as official member thanks to think-cell’s participation in the German national body. In total, 18 different countries sent representatives and over 180 C++ experts attended, although some of them only remotely.

Technique: Proof types to ensure preconditions

Wed, 30 Nov 2022 00:00:00 +0000

Consider a library using hidden global state that needs to be initialized by calling an initialization function. If you don’t call the function before you start using the library, it crashes.

How do you design the library in such a way that it is impossible to use it before initialization?

One idea is to use a technique where you create a special proof type, which needs to be passed as an additional parameter. Let’s look at it in more detail.

New integer types I'd like to see

Thu, 29 Sep 2022 00:00:00 +0000

(Most) C++ implementations provide at least 8, 16, 32, and 64-bit signed and unsigned integer types. There are annoying implicit conversions, discussions about undefined behavior on overflow (some think it’s too much UB, others think it’s not enough), but for the most part they do the job well. Newer languages like Rust copied that design, but fixed the conversions and overflow behavior.

Still, I think there is room for innovation here. Let me talk about three new families of integer types I’d like to see.

malloc() and free() are a bad API

Wed, 31 Aug 2022 00:00:00 +0000

If you need to allocate dynamic memory in C, you use malloc() and free(). The API is very old, and while you might want to switch to a different implementation, be it jemalloc, tcmalloc, or mimalloc, they mostly copy the interface. It makes sense that they do that – they want to be a mostly drop-in replacement, but it’s still unfortunate because malloc() and free() are a bad API for memory allocation.

Let’s talk why.

Carbon's most exciting feature is its calling convention

Fri, 29 Jul 2022 00:00:00 +0000

Last week, Chandler Carruth announced Carbon, a potential C++ replacement they’ve been working on for the past two years. It has the usual cool features you expect from a modern language: useful generics, compile-time interfaces/traits/concepts, modules, etc. – but the thing I’m most excited about is a tiny detail about the way parameters are passed there.

It’s something I’ve been thinking about in the past myself, and to my knowledge it hasn’t been done in any low-level language before, but the concept has a lot of potential. Let me explain what I’m talking about.

Tutorial: Preparing libraries for CMake FetchContent

Wed, 29 Jun 2022 00:00:00 +0000

If you’re working on an executable project in C++, as opposed to a C++ library, using a package manager to get your dependencies might be overkill: If all you need is to get the source code of a library, include in your CMake project, and have it compiled from source with the rest of your project, CMake’s FetchContent module can do it for you.

If you’re a library writer, there are ways you can structure your CMake project to improve the experience for end users that use FetchContent: hide developer targets like tests, provide a zip archive that contains only the source files relevant downstream, and use GitHub actions to create it automatically.

Let’s see how.

Technique: Recursive variants and boxes

Tue, 31 May 2022 00:00:00 +0000

There are many data structures that can be elegantly expressed using sum types. In C++ a (somewhat clunky) implementation of sum types is std::variant. However, it can’t handle recursive data structures, where one alternative contains the entire sum type again.

Let’s see how we can fix that.

`saturating_add` vs. `saturating_int` -- new function vs. new type?

Wed, 30 Mar 2022 00:00:00 +0000

Suppose you want to do integer arithmetic that saturates instead of overflowing. The built-in operator+ doesn’t behave that way, so you need to roll something yourself. Do you write a saturating_add() function or a new saturating_int type with overloaded operator+? What about atomic_load(x) vs. atomic<int> x? Or volatile_store(ptr, value) vs. volatile int*?

When should you provide functions that implement new behavior and when should you write a wrapper type? Let’s look at the pro and cons.

Technique: Compile Time Code Generation and Optimization

Thu, 27 Jan 2022 00:00:00 +0000

C++ constexpr is really powerful. In this blog post, we’ll write a compiler that can parse a Brainfuck program given as string literal, and generate optimized assembly instructions that can then be executed at runtime. The best part: we neither have to actually generate assembly nor optimize anything ourselves! Instead we trick the compiler into doing all the hard work for us.

The same technique can be used whenever you want to specify some sort of “program” in a different way and translate it at runtime: regexes, routing tables, etc.

I accidentally wrote a Turing-complete parsing library

Thu, 25 Nov 2021 00:00:00 +0000

I’m currently working on lexy, a C++ parsing DSL library: you describe how input should be parsed, and lexy generates code for it, taking care of error recovery, parse tree generation, and parse values. Such parser generators are classified based on the expressiveness of the corresponding formal language. For example, a strict regular expression can only parse regular languages, which is a strict subset of a deterministic context free language, and so on.

lexy, being essentially syntax sugar for a recursive descent parser with (manually specified!) arbitrary lookahead but no other state, falls in the latter category. Parsers in that category are unable to parse context-sensitive languages such as XML with matching tags. To handle them, I’ve added support for “context variables”: state that can be modified during parsing.

However, in a recent refactoring of the context variables implementation, I’ve accidentally removed a big limitation, which makes lexy Turing-complete: the parser is thus able to do arbitrary computation while parsing the input.

TL;DR: I’ve written a lexy grammar that is able to execute, not just parse, a simple Turing-complete language.

Tutorial: the CRTP Interface Technique

Tue, 12 Oct 2021 00:00:00 +0000

Generic code expects that your types model certain concepts. Sometimes, the concept requires many redundant member functions in your type. A big culprit here are iterators: they require many operator overloads, most of which are trivially implemented in terms of other overloads.

CRTP, the curiously recurring template pattern, can help here and automate the boilerplate away. Let’s look at the CRTP interface technique and explore how it works.

C++20 concepts are structural: What, why, and how to change it?

Thu, 29 Jul 2021 00:00:00 +0000

C++20 added concepts as a language feature. They’re often compared to Haskell’s type classes, Rust’s traits or Swift’s protocols.

Yet there is one feature that sets them apart: types model C++ concepts automatically. In Haskell, you need an instance, in Rust, you need an impl, and in Swift, you need an extension. But in C++? In C++, concepts are just fancy boolean predicates that check for well-formed syntax: every type that makes the syntax well-formed passes the predicate and thus models the concepts.

This was the correct choice, but is sometimes not what you want. Let’s explore it further.

Tutorial: Interactive code snippets with Hugo and Compiler Explorer

Mon, 31 May 2021 00:00:00 +0000

I’m currently rewriting the documentation for lexy, my C++ parser combinator library – hey, this is the fourth blog post in a row mentioning it in the introduction! It already has an interactive online playground where you can enter a grammar and input and see the resulting parse tree and/or error messages. This is really helpful, so the new documentation will contain examples that are directly available in the playground, to try it out and see what happens.

While implementing this, I’ve realized that this can also be extended to ordinary code snippets on my blog. Without any Javascript or manual work on my part, I can give the code snippet a “play button” that directly links to Compiler Explorer, like this:

Implementation Challenge: Lossless, compact parse tree with iterative traversal

Wed, 28 Apr 2021 00:00:00 +0000

My parser combinator library lexy was originally designed to parse some grammar into a user-defined data structure, comparable to Boost.Spirit. This is ideal for parsing simple “data” grammars like JSON or email addresses, and also works for parsing programming languages: simply parse into your AST. However, by design lexy::parse() will only forward data explicitly produced by the parsing combinators which does not include punctuation, comments, or whitespace.

Inspired by matklad’s blog post about modern parser generators, I’ve decided to add a way to retain all the information and produce a lossless parse tree by calling lexy::parse_as_tree(). This requires no changes to your existing grammar and simply switches the output. With that, I could also add an online playground that visualizes the parse tree of a given grammar on the given input.

Implementing the actual code that produces a parse tree during parsing wasn’t too hard – I’ve already had a handler that controls what happens during parsing to implement lexy::match() and lexy::validate(). The challenging part was the actual data structure for storing a parse tree: it should be memory-efficient, as it can be big, and users should be able to easily iterate over every node without requiring recursion.

Trivially copyable does not mean trivially copy constructible

Thu, 25 Mar 2021 00:00:00 +0000

About a month ago, I got an interesting pull request for lexy, my new parser combinator library. It fixed a seemingly weird issue relating trivially copyable types and special member function of classes containing unions. While digging into it, I learned a lot about trivial special member functions and made a somewhat surprising realization:

Just because a class is std::is_trivially_copyable does not mean the class is actually std::is_trivially_copy_constructible or even std::is_copy_constructible: you can have classes that you can’t copy, but they’re still trivially copyable, and classes where the copy constructor can do arbitrary amounts of non-trivial work, but they’re nonetheless trivially copyable!

Let me explain.

What is the unit of a text column number?

Wed, 17 Feb 2021 00:00:00 +0000

I’ve recently published my parsing combinator library lexy. One of the things it does is issue a lexy::error if the input does not match the grammar. This error has a .position() which gives you the position where the error occurred.

In order to keep the happy path fast, .position() is not something that is easy to use for end users: it is simply an iterator into the input range. This is no good to a human user who wants something like line and column number to easily locate the problematic input.

Converting an iterator into line/column location seems simple enough: set line = column = 1 and iterate over the entire input until you’ve reached the position of the iterator. Every time you see a newline, increment the line number and set the column number back to 1. Otherwise, the column is implemented every time you … see what exactly?

What exactly is a “column” of a text and how do I compute it?

Tricks with Default Template Arguments

Tue, 27 Oct 2020 00:00:00 +0000

Just like regular function parameters, template parameters can also have default parameters. For class templates, this behaves mostly just like default function arguments: if you pass fewer template arguments than required, default template arguments are used to fill the remaining places. However, for function templates, it gets more complicated as template parameters for functions can be deduced by the normal function arguments. This leads to some interesting side-effects. In particular, default arguments of template parameters don’t need to be put at the end!

Let’s take a look at a couple of things we can do with default template arguments.

`constexpr` is a Platform

Mon, 19 Oct 2020 00:00:00 +0000

Let me share a useful insight with you: constexpr is a platform.

Just like you write code that targets Windows or a microcontroller, you write code that targets compile-time execution. In both cases you restrict yourself to the subset of C++ that works on your target platform, use conditional compilation if your code needs to be portable, and execute it on the desired target platform. You can thus view constexpr as another platform you can target; it just so happens to be run by your compiler.

This insight can answer a lot of design questions surrounding constexpr.

Technique: Immediately-Invoked Function Expression for Metaprogramming

Fri, 02 Oct 2020 00:00:00 +0000

Common C++ guidelines are to initialize variables on use and to make variables const whenever possible. But sometimes a variable is unchanged once initialized and the initialization is complex, like involving a loop. Then an IIFE – immediately-invoked function expression – can be used: the variable is initialized by a lambda that computes the value, which is then immediately invoked to produce the value. Then the variable is initialized on use and can also be made const.

I’ve been recently working on a meta-programming library where I found IIFEs useful in a slightly different context – computing type information.

TL;DR: decltype([] { ... } ())!

Implementation Challenge: Replacing std::move and std::forward

Tue, 22 Sep 2020 00:00:00 +0000

When C++11 introduced move semantics, it also added two important helper functions: std::move and std::forward. They are essential when you want to manually indicate that you no longer care about an object or need to propagate the value category in generic code. As such, I’ve used them countless times in the past.

However, they are functions. Plain, old, standard library functions.

This is problematic for multiple reasons.

Nifty Fold Expression Tricks

Tue, 05 May 2020 00:00:00 +0000

Suppose you need to have a variadic function and want to add all arguments together. Before C++17, you need two pseudo-recursive functions:

template <typename H, typename ... T>
auto add(H head, T... tail)
{
    return head + add(tail...);
}

template <typename H>
auto add(H head)
{
    return head;
}

However, C++17 added fold expressions, making it a one-liner:

template <typename H, typename ... T>
auto add(H head, T... tail)
{
    return (head + ... + tail);
    // expands to: head + tail[0] + tail[1] + ...
}

If we’re willing to abuse operator evaluation rules and fold expressions, we can do a lot more. This blog posts collects useful tricks.

Tutorial: C++20's Iterator Sentinels

Wed, 25 Mar 2020 00:00:00 +0000

You probably know that C++20 adds ranges. Finally we can write copy(container, dest) instead of copy(container.begin(), container.end(), dest)!

Ranges also do a lot more. Among other things, they add a new way of specifying an iterator to the end – sentinels.

std::polymorphic_value + Duck Typing = Type Erasure

Fri, 17 Jan 2020 00:00:00 +0000

I recently had an insight about type erasure that I wanted to share. Type erasure is a combination of two techniques working together to achieve both polymorphism and value semantics: std::polymorphic_value, a proposed standard library type, and duck typing.

Naming Things: Implementer vs. User Names

Wed, 27 Nov 2019 00:00:00 +0000

I wanted to write this blog post about (a specific part of) naming things back in July, but ironically I didn’t have a name for the symptom I wanted to describe. I only found a good name when I attended Kate Gregory’s talk on naming at CppCon, and now I finally have the time to write my thoughts down.

So I want to write about naming. In particular, about the phenomenon that sometimes a name is a perfect description of what a function does, yet it is totally useless.

Standardese Documentation Generator: Post Mortem and My Open-Source Future

Tue, 05 Nov 2019 00:00:00 +0000

Back in 2016, I started standardese, a C++ documentation generator. However, in the past two years I haven’t really worked on it.

Now, I can officially announce that I have abandoned the project and transferred ownership. This blog post explains why.

Tutorial: When to Write Which Special Member

Tue, 26 Feb 2019 00:00:00 +0000

When explaining someone the rules behind the special member functions and when you need to write which one, there is this diagram that is always brought up. I don’t think the diagram is particularly useful for that, however.

It covers way more combinations than actually make sense. So let’s talk about what you actually need to know about the special member functions and when you should write which combination.

Nested Optionals, Expected and Composition

Tue, 11 Dec 2018 00:00:00 +0000

Andrzej wrote about problems with CTAD and nested optionals, then Barry wrote about problems with comparison and nested optionals.

What do both problems have in common?

Nested optionals.

So let’s talk about them: What do they actually mean?

Inline Namespaces 101

Thu, 22 Nov 2018 00:00:00 +0000

Almost three years ago — wow, how time flies — I blogged about namespace aliases and called them one of C++ most underrated features (which probably was a bit of a click bait).

Let’s talk about some other namespace feature, that is, well, not quite underrated, but relatively obscure: inline namespace. They are namespaces that don’t really introduce a scope, except when they do.

So what can you do with them?

Tutorial: Managing Compiler Warnings with CMake

Wed, 17 Oct 2018 00:00:00 +0000

Warnings are important, especially in C++.

C++ compilers are forced to accept a lot of stupid code, like functions without return, use of uninitialized warnings, etc. But they can at least issue a warning if you do such things.

But how do you manage the very compiler-specific flags in CMake?

How do you prevent your header files from leaking warnings into other projects?

Proposals to Fix the Spaceship Operator

Sat, 13 Oct 2018 00:00:00 +0000

I did a series about comparisons recently where I gave some guidelines about using the upcoming spaceship operator for three-way comparison. In particular, I pointed out a couple of flaws with the design as it is currently.

Well, now the proposals for the next C++ standardization meeting are here — almost 300 of them. And I’ve counted eleven of them that deal with the spaceship operator.

So let’s take a look and them and see whether they’ll fix any of the issues I’ve pointed out.

Mathematics behind Comparison #5: Ordering Algorithms

Mon, 01 Oct 2018 00:00:00 +0000

In order to sort a collection of elements you need to provide a sorting predicate that determines when one element is less than the other. This predicate must “induce a strict total ordering on the equivalence classes” according to cppreference. Wait, what?

The upcoming C++ spaceship operator implements a three-way comparison, i.e. it is a single function that can return the results of <, == and > combined. But related to it are terms like “strong equality” and “weak ordering” which are somewhat confusing if you don’t have the mathematical background.

So let’s untangle it: This series will explain both the mathematics behind equality and ordering, as well as give concrete guidelines for implementing the comparison operators and the spaceship operator.

To finish this series let’s talk about algorithms that require an ordering and how they can be implemented using three-way comparison.

Mathematics behind Comparison #4: Three-Way Comparison

Fri, 07 Sep 2018 00:00:00 +0000

Now that we’ve covered both equivalence and ordering relations we can finally talk about the spaceship operator and three-way comparisons.

Mathematics behind Comparison #3: Ordering Relations in C++

Thu, 19 Jul 2018 00:00:01 +0000

The upcoming C++ spaceship operator implements a three way comparison, i.e. it is a single function that can return the results of <, == and > combined. But related to it are terms like “strong equality” and “weak ordering” which are somewhat confusing if you don’t have the mathematical background.

The previous part was very math heavy but necessary: It introduced the mathematical terminology for ordering relations. With that done we can finally talk about how it applies to C++.

Mathematics behind Comparison #2: Ordering Relations in Math

Thu, 19 Jul 2018 00:00:00 +0000

This part covers the mathematics behind ordering relations. They are a lot more complicated than equivalence relations we’ve looked at before. As my blog posts are usually long anyway, I’ve decided to split it into two. So this part is only about the mathematics while the next part—already published—is about how they should be implemented in C++.

Let's Talk about std::optional and optional references

Thu, 12 Jul 2018 00:00:00 +0000

This should have been part 2 of my comparison series, and I have almost finished it, but due to university stuff I just haven’t found the time to polish it.

But the optional discussion started again, so I just wanted to really quickly share my raw thoughts on the topic. In case you are lucky and don’t know what I mean: std::optional<T&> doesn’t compile right now, because the behavior of assignment wasn’t clear (even though it actually is). There are basically four questions in the discussion I want to answer:

Is std::optional<T&> the same as a pointer?
Do we need std::optional<T&>?
Should the assignment operator rebind or assign through?
Should it even have an assignment operator?

tl;dr: no, I don’t, rebind, no.

Mathematics behind Comparison #1: Equality and Equivalence Relations

Wed, 20 Jun 2018 00:00:00 +0000

This part covers equality and equivalence relations. What does it mean for two objects to be equal? What are the mathematical properties and C++ semantics it needs to fulfill? How do I implement proper equality comparison in C++?

In the following parts we’ll look at ordering relations, the new three way comparison and algorithms like sorting and searching on various orderings.

A (Better) Taxonomy of Pointers

Fri, 01 Jun 2018 00:00:00 +0000

At C++Now 2018 I gave a talk about rethinking pointers: jonathanmueller.dev/talk/cppnow2018.

I highly recommend you check it out, even if you watched the similar talk I gave at ACCU, as that version is a lot better. It rediscovers and discusses the common guidelines about when to use references over pointers, when smart pointers, etc.

If you’re an expert, you might get a deeper meaning from the structured analysis. And if you’re a beginner, you get the condensed guidelines.

However, I think the most valuable thing is the taxonomy of pointer types. It gives new vocabulary when talking about T* vs std::optional<T&> which gives the whole discussion an obvious answer.

And here is also the big problem: Naming is hard.

In particular, my naming of the taxonomy in the talk is bad, so let’s introduce new names.

optional in Containers Ⅱ — Not All std::vector Usages Are The Same

Tue, 17 Apr 2018 00:00:00 +0000

Okay, so in the previous post I talked about putting optional<T> in container. I came to conclusions which I though were reasonable at the time, however, people — rightfully — pointed out some flaws in my argumentation.

As I was at ACCU last week, I wasn’t able to respond to them earlier (note to self: don’t publish and then fly away to a conference), so I’m doing that now. Let’s revisit my argumentations and see where I was wrong.

Should You Put optional in a Container?

Mon, 09 Apr 2018 00:00:00 +0000

Title says it all: should you put std::optional<T> in a container?

To answer that we have to take a slight detour first.

Guidelines For Rvalue References In APIs

Mon, 26 Mar 2018 00:00:00 +0000

I’ll be giving a talk at ACCU about when to use which pointer types and why.

While working on that I made some guidelines for rvalue references in interfaces which didn’t quite fit the talk, so I’m writing about them here.

When should you use rvalue references as function parameters?

When as return types?

What are ref-qualified member functions and when and how should you use them?

Let’s tackle it one by one.

Flexible issue management with Trello and IFTTT

Thu, 15 Mar 2018 00:00:00 +0000

Like many open source developers I use GitHub to publish my work. It comes with a built-in issue tracking system, however, it isn’t that great.

The main issue - no pun intended - I have with it is that there is not an easy way to see all open issues and pull requests on all repositories you have. There is the issue workspace, but it only shows issues I’ve created, where I’m mentioned, or I’m assigned to. This isn’t helpful in my case, so I’ve looked for a different solution. There are also so-called “Projects”, but they are just for one repository - I need one for all.

I finally found a solution: It uses Trello and If This Then That.

Guidelines for constructor and cast design

Fri, 26 Jan 2018 00:00:00 +0000

A while back — but sadly not too many blog posts ago — I wrote about explicit constructors and how to handle assignment. In this blog post, I made the assumption that you most likely want to have explicit single argument constructors.

But when do we actually want implicit single argument constructors?

Let’s consider the broader question: How should I design a cast operation for my user-defined type? And how should I design a constructor?

But first, something different: what is the difference between a cast and a constructor?

Implementation Challenge: Revisiting the visitor pattern

Thu, 21 Dec 2017 00:00:00 +0000

C++ as a language is moving away from the classical, “Java style”, object-oriented programming. Long gone are the days of grand, virtual hierarchies. They’ve been replaced with standalone classes, free functions and type erasure.

And the benefits are clear: Instead of reference semantics, they allow value semantics which are simpler and more natural for C++. Instead of intrusive interface inheritance, they allow external duck-typing.

So in the spirit of this movement, let’s take a look at one OOP pattern and see if we can adopt it to this style: the visitor pattern.

Exceptions vs expected: Let's find a compromise

Mon, 04 Dec 2017 00:00:00 +0000

This isn’t the blog post I wanted to publish today, this is the blog post I had to publish.

Simon blogged about using ADTs for error handling, leading to an interesting reddit discussion. Then Vittorio wanted to share his thoughts on the matter, leading to an even bigger reddit discussion. Now I’d like to chime in and offer a reasonable solution.

It is the age-old question: return codes vs exceptions. But this time, return codes have gotten an upgrade: std::expected and similar types.

What should be part of the C++ standard library?

Mon, 20 Nov 2017 00:00:00 +0000

At Meeting C++ 2017 — which was great, BTW — I attended a talk by Guy Davidson about the C++ graphics 2D proposal, wording here.

Now, there is some controversy about the proposal — especially by those who do serious graphics stuff. Does the C++ standard library need 2D graphics? Shouldn’t the committee focus on real issues instead of some toy library that is never going to be used for serious applications?

But I’m not here to rant about the stupid standard committee and the completely bloated and unusable standard library, like some do. Instead, this discussion got me thinking: What should be part of a language’s standard library?

Write explicit constructors - but what about assignment?

Wed, 11 Oct 2017 00:00:00 +0000

Implicit conversions considered harmful.

Okay, this might be a little harsh:

Potentially dangerous and/or expensive implicit conversions considered harmful.

Better.

Implicit conversions will happen “accidentally” by their very nature, so if they happen, they should always do the right thing.

And how to prevent implicit conversions? Simple: use an explicit constructor.

But that’s only half of the problem: What about assignment? Is there explicit assignment? If so, when do I use it?

Thoughts on destructive move

Thu, 14 Sep 2017 00:00:00 +0000

C++11 introduced move semantics. With it, you can encode transfer of ownership and allow to put types in a container where you can’t copy them.

This clearly is powerful.

But the current move system isn’t perfect, there are a couple of issues. There is an arguably cleaner approach: destructive move.

In this post we’ll explore a purely theoretical alternative C++ with destructive move.

Operator precedence is broken

Mon, 24 Jul 2017 00:00:00 +0000

A discussion on Twitter got me thinking about operator precedence. It is a crucial part of most programming languages as it dictates the meaning of expressions.

Interestingly enough, it is practically the same in almost all programming languages, even ones that radical try to be a better alternative for an established language. So apparently operator precedence is a solved problem, right?

Well, I don’t think so. I think operator precedence is fundamentally flawed and could easily be improved.

Lazy evaluation of function arguments in C++

Tue, 27 Jun 2017 00:00:00 +0000

Sometimes you’re lazy. You know you need to do something, but don’t want to do it yet. You don’t need to do it right now, only at some later point. And maybe later it turns out that you don’t need to do the entire work, just a part of it or nothing at all! So if you’re eager and do it right now, you might do more work than needed.

The same applies to your code. Sometimes you do things even though it is not necessary. You call a function passing it some arguments that were expensive to calculate and then the function don’t need all of them due to some other arguments. Wouldn’t it be great to only calculate the arguments when they are actually needed?

This is called lazy evaluation of function arguments and this blog post presents how it can be done in C++.

Prefer nonmember, nonfriends?

Wed, 14 Jun 2017 00:00:00 +0000

How many member functions does std::string have?

As of C++17 the answer is 153, assuming I counted correctly.

One Hundred Fifty Three.

That is a lot. And as Herb Sutter has pointed out, most of those members could easily be implemented as non-members without loss of performance.

And they should be implemented as nonmembers according to an old guideline from the C++ coding standards: Prefer nonmember, nonfriends. Write free functions whenever possible, not members.

But how true is that advice really?

The year is 2017 - Is the preprocessor still needed in C++?

Mon, 08 May 2017 00:00:00 +0000

The C++, eh C, preprocessor is wonderful.

Well, no - it isn’t wonderful.

It is a primitive text replacement tool that must be used to work with C++. But is “must” really true? Most of the usage has become obsolete thanks to new and better C++ language features. And many more features like modules will come soon™. So can we get rid of the preprocessor? And if so, how can we do it?

cppast - A library to parse and work with the C++ AST

Thu, 20 Apr 2017 00:00:00 +0000

Last year I started standardese, a C++ documentation generator. In order to provide exact documentation, I need to parse C++ code. As I didn’t want to waste time implementing my own parser, which will take ages and don’t work most of the time, I opted to use libclang.

libclang is a C API that exposes the C++ abstract syntax tree (AST) which is built on top of clang. And clang is a good and conforming C++ compiler, so I expected an interface to read the AST that just works and give me the information I need.

Well, I was wrong. Here’s why and how I solved it.

std::string_view accepting temporaries: good idea or horrible pitfall?

Wed, 22 Mar 2017 00:00:00 +0000

C++17 brings us std::string_view. It is a really useful tool: If you want to write a function accepting some string, but does not need ownership, i.e. a view, use std::string_view. It supports both const char* and std::string without any work, and does not involve any heap allocations. Further, it clearly signals intent: this function takes a view. It doesn’t own anything, it just views it.

As someone who frequently advocates for using correct types, I am happy about std::string_view. Yet there is one design decisions that warrants a discussion: std::string_view silently views temporaries as well. This can create a problem if the view lives longer than the temporary, as the view now views already destroyed data.

Let’s look into the reasons behind this decision and what that means for using std::string_view.

Implementation Challenge flag_set: Type-safe, hard to misuse bitmask

Thu, 16 Mar 2017 00:00:00 +0000

Sometimes when writing an API you need to pass various flags to a function. For example, when opening a file you can pass information like whether or not the file is opened for reading, writing, binary, write at the end etc. And often those flags can be combined arbitrarily.

Usually you’d implement that by using a bitmask: Each flag is a bit in an integer, they can be set/reset and toggled with bitwise operations. However, the naive implementation isn’t very good: I’ll explain why and show you how to do it better.

Implementing a tuple_iterator

Wed, 01 Mar 2017 00:00:00 +0000

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.

The problem with policy-based design

Wed, 08 Feb 2017 00:00:00 +0000

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.

Implementing function_view is harder than you might think

Fri, 20 Jan 2017 00:00:00 +0000

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.

How to handle errors in constructors without exceptions?

Mon, 09 Jan 2017 00:00:00 +0000

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

Comment from discussion Measuring execution performance of C++ exceptions vs plain C error codes.

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?

My take on variant

Wed, 28 Dec 2016 00:00:00 +0000

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.

Tutorial: Conditionally disabling non-template functions

Wed, 21 Dec 2016 00:00:00 +0000

Consider that you have a function template that takes a parameter on type T. If the function template has a rather generic name like operator==, is a constructor, or anything whose existence might be queried with type traits to further constrain other functions, it is often beneficial if you can conditionally disable the function if the type does not have some required properties. Otherwise the function will be “greedy” and accept more than it should - making some traits near useless, as they only check for existence and the error only occurs later.

Conditionally removing functions if their template parameters don’t fulfill certain properties is done with SFINAE. But what if you have member functions of a class template that are not templates themselves?

Fixing std::initializer_list

Thu, 08 Dec 2016 00:00:00 +0000

C++11 introduced std::initializer_list. This is a small class used if you want to initialize some container type with a pre-defined set of elements. It allows very convenient syntax just like plain old C arrays have.

Yet it has a couple of problems. This post will talk about them and how they can be fixed.

standardese documentation generator version 0.3: Groups, inline documentation, template mode & more

Sat, 26 Nov 2016 00:00:00 +0000

After two bugfix release for the parsing code, I finally got around to implement more features for standardese. A complete refactoring of the internal code allowed me to implement some advanced features: standardese now comes with member groups, the ability to show inline documentation, a template language and many minor things that just improve the overall documentation generation.

Memory 0.6: Composition and Joint Allocators

Mon, 21 Nov 2016 00:00:00 +0000

If you’ve been a long reader of my blog, you might remember my memory library. I haven’t forgotten about it, even though the 0.5 release was in February! After three patches and a long pause in development to focus on standardese, I’ve finally finished the 0.6 release. It mainly provides two major features: composition and joint allocators.

Function templates - deduce template arguments or pass explicitly?

Fri, 04 Nov 2016 00:00:00 +0000

Function templates allow writing a single definition that can handle multiple different types. It is a very powerful form of C++’s static polymorphism.

When instantiating a class template, we have to pass in the types explictly (at least until C++17):

std::vector<int> vec;
std::basic_string<my_char, std::char_traits<my_char>> str;
std::tuple<int, bool, std::string> tuple;

But when instantiating a function template, the compiler can often figure the types out:

template <typename A, typename B, typename C>
void func(const A& a, const B& b, const C& c);
…
int x;
func(x, 'A', "hello");
// equivalent to:
func<int, char, const char*>(x, 'A', "hello");

Let’s look at this process into a little bit more detail and establish some guidelines as well as see how we can prohibit template argument deduction for arguments.

void foo(T& out) - How to fix output parameters

Wed, 26 Oct 2016 00:00:00 +0000

There are some cases where you need to return a value from a function but cannot use the return value. It happens, for example, in functions where you want to return multiple values at once. While you can pass multiple inputs to a function - the parameters, you cannot pass multiple return values in the same way.

C++ programmers tend to use a good old (lvalue) reference for that. You take a non-const reference as parameter and assign the output to that reference. The caller will pass a variable and upon function completion find the value of the variable changed.

Yet this approach has some problems: For starters, it is not obvious when just looking at the call that the variable is going to be changed. This is the reason that C++ style guides such as the one used by Google recommend using a pointer for that. The caller then has to explicitly pass in the address of the variable, making it explicit.

But with a pointer you can now pass in nullptr, you have to check for that in the function: A pointer where you really mean “reference” does not follow the guidelines I’ve been advocating for.

So is there not a universal solution?

There is, but first we need to understand the full scope of the problem.

Tutorial: Emulating strong/opaque typedefs in C++

Wed, 19 Oct 2016 00:00:00 +0000

Last week, I’ve released my type_safe library. I described it’s features in the corresponding blog post but because the blog post got rather long, I couldn’t cover one feature: strong typedefs.

Strong or opaque typedefs are a very powerful feature if you want to prevent errors with the type system – and as I’ve been advocating for, you want that. Unlike “normal” typedefs, they are a true type definition: they create a new type and allow stuff like overloading on them and/or prevent implicit conversions.

Sadly, C++ doesn’t provide a native way to create them, so you have to resort to a library based emulation.

BTW, type_safe received a couple of requested features: There are improvements to the monadic optional functions (bind(), map(), unwrap() as well as a new transform()), multi-visitation of optionals and ArithmeticPolicy to control over/underflow behavior of the ts::integer<T>.

Type safe - Zero overhead utilities for more type safety

Tue, 11 Oct 2016 00:00:00 +0000

Two weeks ago I’ve blogged about using C++’s type system to prevent errors. The post spawned a lot of discussion so I wanted to address some of the responses I’ve got. I’ve also said at the end of the post that I was going to write a library that helps to implement the techniques. The library is now done - type_safe can be found on Github, but please do read on for a discussion about the motivation and feature overview.

Prevent precondition errors with the C++ type system

Tue, 27 Sep 2016 00:00:00 +0000

In the previous part of the error handling series I’ve talked about assertions and wrote a debug assert library that provides flexible assertions.

Assertions are a useful tool to check preconditions of functions - but proper type design can prevent situations where assertions are needed. C++ has a great type system, let’s use it to our advantage.

At the recent CppCon Ben Deane gave a - as far as I’ve heard - great talk about type design. I sadly didn’t attend the conference and his video isn’t released yet but according to the slides there is some overlapping between his talk and what I’m going to say. But because I’ve planned this posts for weeks and even made the entire series just for it I decided to post it anyway. After all: some things cannot be said often enough.

Also I’m going to focus explicitly about type design for error handling, while his talk seems to be more generic.

How do I implement assertions?

Fri, 16 Sep 2016 00:00:00 +0000

In part 1 of the series I’ve talked about various error handling strategies and when to use which one. In particular, I said that function precondition should only be checked with debug assertions, i.e. only in debug mode.

The C library provides the macro assert() for checking a condition only if NDEBUG is not defined. But as with most things coming from C, it is a simple but sometimes not sufficient solution. The biggest problem I have with it is that it is global, you either have assertions everywhere or none. This is bad, because you might not want to have assertions enabled in a library, only in your own code. For that reason, many library programmers write an assertion macro themselves, over and over again.

Instead, let’s write same thing better ourselves, but something we can easily reuse.

Implementation Challenge: Concepts in C++14

Fri, 09 Sep 2016 00:00:00 +0000

There is the concept TS, a technical specification for including concepts into C++17. Concepts have always been a … concept in C++. They are used to document constraints on template parameters. For example:

template <typename RandomAccessIterator, typename Comperator>
void sort(RandomAccessIterator begin, RandomAccessIterator end, Comperator comp);

This function has the requirement that begin and end are both random access iterators and comp is a comparison function. Right now, the concepts are only documented and ignoring them leads to great error messages. The concept TS provides ways to embed them in the language directly and make, for example, overloading based on the concept easier.

But it doesn’t really bring anything new to the language. Everything it does can be accomplished with C++11’s expression SFINAE today, it only brings an (arguably) cleaner syntax and more complexity to the language.

In this post I’ll show you how to do implement concepts using only C++14 language features. I’ll try to make it as easy as possible by introducing some library utilities you can use very easily.

Choosing the right error handling strategy

Wed, 07 Sep 2016 00:00:00 +0000

To quote a previous post: “Sometimes things aren’t working.” If something isn’t working, you have to deal with it. But how?

There are two fundamental kinds of strategies: recoverable error handling (exceptions, error return codes, handler functions) and un-recoverable error handling (assert(), abort()). When do I use which one?

Move Semantics and Default Constructors -- Rule of Six?

Wed, 24 Aug 2016 00:00:00 +0000

A really long time ago - over four weeks! - I wrote about move safety.

I really need to force myself into blogging on a schedule. Let’s say I’ll publish something at least every two weeks.

The post spawned a lot of discussion about whether you should rely on moved-from state behavior or make any guarantees. See the first half of this CppChat episode for more.

BTW: Thanks for the nice words, Jon! Really appreciate it.

But I’m not going to continue that discussion. Both sides have convincing arguments and I don’t really want to advocate for one side here.

Instead I’m going to talk about something else related to the C++ move semantics, that couldn’t fit into the original post: The relationship between a default constructor and move semantics.

Standardese documentation generator version 0.2: Entity linking, index generation & more

Wed, 10 Aug 2016 00:00:00 +0000

Two months ago I’ve released standardese version 0.1. I promised that the next version wouldn’t take so long as the first one - which took one month.

Well, I’m really not good as estimates.

But this release brings the last missing features to make standardese an actually usable documentation generator: index generation, referring to other parts of the documentation and more output formats, as well as other amazing features like an overhauled comment system. Also a lot of internal changes and bug fixes.

Move Safety -- Know What Can Be Done in the Moved-From State

Sat, 23 Jul 2016 00:00:00 +0000

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.

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

Thu, 07 Jul 2016 00:00:00 +0000

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

Comment from discussion Is there a C++ package manager? If not, how do you handle dependencies?.

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.

Flexible error handling techniques in C++

Mon, 27 Jun 2016 00:00:00 +0000

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.

Standardese documentation generator version 0.1

Thu, 09 Jun 2016 00:00:00 +0000

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.

You (probably) do want `final` classes?

Sun, 29 May 2016 00:00:00 +0000

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.

You (probably) don't want `final` classes

Fri, 27 May 2016 00:00:00 +0000

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.

Issue driven development

Sat, 21 May 2016 00:00:00 +0000

A few weeks ago I tweeted the following:

I'm now doing issue driven development using Gogs.

It is *really* great, I can now measure how much I've done and plan better.
— Jonathan Müller (@foonathan) April 16, 2016

I was requested to give a review about it:

. @irrequietus I'll file an issue. :D
— Jonathan Müller (@foonathan) April 16, 2016

This is basically the workflow I’m doing for issue driven development.

Standardese - a (work-in-progress) nextgen Doxygen

Fri, 06 May 2016 00:00:00 +0000

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.

How I have beaten Boost.Pool #4: About abstractions and algorithms

Mon, 18 Apr 2016 00:00:00 +0000

And apparently also about alliterations.

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.

How I have beaten Boost.Pool #3: Branches are bad

Wed, 13 Apr 2016 00:00:00 +0000

Yes, exaggerated title.

Branches and conditional jumps are essential for every program, you cannot write anything but the most trivial code without them. Yet they sometimes have a certain overhead and can lead to problems in performance critical code paths.

It is often faster if they weren’t there. But how can you do that?

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned in the process of beating Boost.Pool. This time its all about branches and a more detailed information about the detail::small_free_memory_list.

(Awesome?) Allocator Additions - Thoughts regarding allocator proposals

Mon, 04 Apr 2016 00:00:00 +0000

The C++ Standards Committee Papers of the post-Jacksonville mailing were recently published. There are few quite interesting ones that deal with the STL’s allocator model: P0177R1 - Cleaning up allocator_traits, P0178R0 - Allocators and swap(actually from February) and P0310R0 - Splitting node and array allocation in allocators.

In this post, I’d like to discuss those with you and explain why I really hope some of them they will accepted. The first parts are also a follow-up to AllocatorAwareContainer: Introduction and pitfalls of propagate_on_container_XXX defaults.

How I have beaten Boost.Pool #2: Inlining is key

Tue, 29 Mar 2016 00:00:00 +0000

Calling a function has a certain overhead. Registers must be saved, a new stack frame pushed,… For small functions this overhead is more than the actual implementation of the function!

For those, it is much better if the compiler would copy-paste the implementation directly into the call site. This is what inlining does.

Luckily, the compiler is usually able to do this optimization. Or can it?

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned in the process of beating Boost.Pool. This time I’m going to cover inlining. I’m going to share some of guidelines I’ve learned and also going to give you a look into some of memory`s internal code and design.

How I have beaten Boost.Pool #1: Introduction and profiling results

Fri, 18 Mar 2016 00:00:00 +0000

When I’ve released memory 0.5, a guy on reddit asked how my library compared to Boost.Pool. I provided a feature comparison and also quickly profiled both Boost’s and my implementation. Sadly, Boost.Pool did beat my library - in most cases.

So over the last weeks, I’ve took care of my performance problems and rewrote my implementations. So in version 0.5-1 they are basically still using the same algorithm, but now my library is equal or faster than Boost.Pool.

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned doing them. The first part is an introduction to the different allocation algorithms used here and gives an overview about the profiling results.

Performing arbitrary calculations with the Concept TS

Thu, 10 Mar 2016 00:00:00 +0000

Last Tuesday I took a closer look at the Concept TS. This followed a discussion about the power and usefulness of concepts regarding a replacement for TMP (shout-out to @irrequietus and @Manu343726). So after compiling the GCC trunk that has concept support, I’ve specifically looked in a way to use concepts alone for doing arbitrary calculations.

Attention: This is completely pointless. You’ve been warned.

For that, I tried to implement a Prime_number concept that checks whether a given number is a prime number. It should use only concepts and require to do the calculation.

Tutorial: Easily supporting CMake install and find_package()

Thu, 03 Mar 2016 00:00:00 +0000

As of version 0.5 my memory library now provides support for system-wide installation and CMake’s find_package().

Because I’ve spent hours of trial and error to come up with it, I’ll document it here. In this post, I will show you how to install your library so that it can be used easily by other projects. In particular, the system will be able to handle multiple installed versions and multiple configurations.

Throughout this post, I’ll be assuming a 3.x CMake version and an already existing CMake project.

Memory 0.5: Better build system, Low-level Allocators, BlockAllocator & Your Feedback is needed

Tue, 23 Feb 2016 00:00:00 +0000

I thought the last release has taken a long time, this one took even longer for less changes! But now foonathan/memory is finally released. This time things get low-level to allow a better high-level.

foonathan/memory is a library providing various memory allocators and adapter classes. Those allocators use a new RawAllocator concept that is simpler than STL’s Allocator and allows better control over the allocation aspect. Adapters and traits ensure compatibility with the existing model, allowing usage in STL or other containers.

Implementation Challenge: A count leading zeroes function

Thu, 11 Feb 2016 00:00:00 +0000

When doing arithmetic in a programming language there is the arcane art of optimizing with the help of bit-wise operations. Of course I’m talking about Bit Hacks.

On a readability and maintainability ranking from 1 to awk Bit Hacks reach a level of Brainfuck. Yet they can be an incredibly low-level optimization useful to tweak the last bit of performance out of an operation but are difficult to get right and 100% portable.

In this post we’ll take a look at a rather easy function - clz(x) that will return the number of leading zero bits in an unsigned integer type x. In particular I’ll show you how to properly wrap GCC’s __builtin_clz().

One of C++ most underrated features: Namespace aliases

Tue, 26 Jan 2016 00:00:00 +0000

About two months ago I wrote the following r/cpp comment:

Comment from discussion FunctionalPlus: helps you write concise and readable C++ code..

In the thread a new library was presented. One user complained about the long namespace name, (s)he got the above replies. Judging by the number of upvotes, people seemed to agree with my comment. In this blog post I am going to elaborate it.

But first, let me tell you a little story about me.

Implementation Challenge: Traits for Concepts with optional functionality

Tue, 15 Dec 2015 00:00:00 +0000

Traits classes are very powerful. They allow to associate information and functionality with arbitrary classes in a non-intrusive way. This makes it possible to use any type in a certain template as long as all access is done through the traits and there is an appropriate specialization.

The default specialization often just forwards to a member function. But for some functionality the types don’t necessarily need to provide it, it’s optional. Then the traits define a default implementation that is used as a fallback. In this post, I will show you how to implement such traits classes.

Controlling overload resolution #4: SFINAE

Mon, 30 Nov 2015 00:00:00 +0000

Overload resolution is one of C++ most complicated things and yet it works most of the time without the need to think about it. In this mini-series, I will show you how to control this complex machinery so it is even more powerful and completely under your control.

The fourth post shows you a weirdly named and powerful alternative to tag dispatching: SFINAE.

Controlling overload resolution #3: Tag dispatching

Mon, 16 Nov 2015 00:00:00 +0000

The third post shows you the power of tag dispatching to select from multiple implementations of a (templated) function. This allows powerful optimization for types with special properties.

Controlling overload resolution #2: Improving error messages for failed overload resolution

Mon, 02 Nov 2015 00:00:00 +0000

The second post shows you a simple way to improve the error messages when overload resolution fails and how to customize it completely.

Controlling overload resolution #1: Preventing implicit conversions

Fri, 16 Oct 2015 00:00:00 +0000

The first post shows you how to delete candidates and how you can use that to prevent implicit conversions.

AllocatorAwareContainer: Introduction and pitfalls of propagate_on_container_XXX defaults

Mon, 05 Oct 2015 00:00:00 +0000

While I was writing the std_allocator adapter of foonathan/memory I’ve learned some not so well-known facts about the STL Allocator and AllocatorAwareContainer concepts I’d like to share. Let’s take a deep breath and dive in into an aspect of the STL containers that isn’t that well covered: Allocator storage.

I will explain the comparison properties of Allocators, show the C++11 propagate_on_container_XXX traits and how the combination of the two can lead to an unnecessary pessimization and a probably not widely known case of undefined behavior.

Memory 0.4: Polishing, Error handling, Storage, Traits, Documentation and more

Sat, 12 Sep 2015 00:00:00 +0000

It took a really long time - three months minus one day - but I have finally finished version 0.4 of foonathan/memory. The release contains a lot of changes and has more than doubled the number of commits.