Blog

Building multi-threaded software in C++ has many pitfalls. One of them is ending your threads. When you want to cleanly shut down your application, how do you make sure all threads exit? C++20 added std::jthread, which helps you in getting the message that the thread should end into your threads. But how do you actually stop your threads?

There is no universal answer to this, of course. Whatever code is running in your threads must check for some exit condition and then exit. There is one especially difficult case, however: What if some of your threads are blocked in a system call? This article describes a strategy of how you can still achieve a clean end in your threads in these cases - as long as you are on Linux.

If you’re building software tuned for performance (in C++ or a similar language), you probably know this as a golden rule: Avoid memory allocations in your performance-critical code at (almost) all costs. However, sometimes that’s just not feasible and you need to make sure that your allocations are as efficient as possible.

In a recent project of mine (where performance is not of utmost importance, but also not negligible), I am not only in the situation that I need to allocate lots of small-ish objects with high frequency, but I also want to use std::shared_ptr for memory safety reasons.

In this article, I look into how pool allocators (especially boost::pool_allocator) can help in this situation.

Emacs has been my daily driver for software development and various other tasks for quite some time. I usually use it on Linux, but at my current job, I am forced to run Windows as my main OS. Fortunately the Windows Subsystem for Linux (WSL) has become pretty usable, especially since MS added a bundled Wayland server that integrates into the Windows desktop (called WSLg).

However, one thing that kept annoying me: Copying text out of my Emacs (running in WSL/WSLg) into any Windows application did not work. I would expect that if I kill some text in Emacs (using e.g. kill-ring-save, bound by default to M-w), the text somehow makes its way to the Windows clipboard and can be pasted into any Windows application.

Modern C++ has many neat RAII-based solutions for managing resources. However, every now and then one needs to manually make sure that some code is run when a resource is not needed anymore. One great solution to this problem is a scope guard. The concept is already very old, however I have surprisingly rarely seen them used (and used them too rarely myself). This article describes the concept, shows how to use it and gives some background on scope guards.

I often encounter variations of the following problem: You are given two or more lists (as e.g. std::vector) of elements and you want to sort them “in parallel”, using one of the lists as keys. I always found the solutions to these kind of problems to be clunky - but with C++23 (or the excellent range-v3 library) we get a very elegant way of doing this.

In fact, CodeChecker is much more than just a front-end to Clang’s Static Analyzer (clangsa from here on…) - but using it just to drive clangsa is already awesome enough that I think you should use it to hunt for bugs in your C++ projects.

In this article, I’ll show how to set up and use CodeChecker for a quick one-off analysis of a CMake based C++ project, and outline how to use CodeChecker in a collaborative setting with the option of integrating it into a CI system. If you are not on C++, CodeChecker might still be for you, as it also supports multiple analyzers for e.g. Java, Python, Go, or JavaScript.

std::vector has the interesting property of allowing to be used with incomplete types to a small degree. However, many legacy (and not-so-legacy) code bases use it in ways which are not allowed by the standard, and which do start breaking with C++20. In this article I’ll explain the limitations, a mistake I’ve seen several times now and why this starts breaking now.

When optimizing code for performance, it is often useful to have a very clear idea about what happens in memory. Reducing page faults, cache misses, TLB misses et cetera can be a major factor in speeding up your code. In this post I will demonstrate how you can inspect paging information regarding the memory of your process under Linux.

One C++17 problem I come across every now and then is to determine whether a certain class or function template specialization exists - say, for example, whether std::swap<SomeType> or std::hash<SomeType> can be used. I like to have solutions for these kind of problems in a template-toolbox, usually just a header file living somewhere in my project. In this article I try to build solutions that are as general as possible to be part of such a toolbox.

I recently needed to trace some error related to C++17 class template argument deduction and came across some corner cases. In this article, I document what I learned, show some “paradox” cases (which have nice, clean solutions as per the standard) and demonstrate a suspected Clang bug.

Up until recently, I pretty much exclusively used git as my VCS system. At my new job, we use Mercurial, at which I had (and still have) a steep learning curve. This article describes a pitfall with hg pull --rebase that I’ve fallen into twice now and that can cause you to accidentially merge branches.