Lukas Barth

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 currently build a piece of software which will need a lot of bog-standard SQL queries against an in-memory database. I was (and am) going with SQLite, but a good friend of mine who Knows About Databases™ told me recently that currently, DuckDB is the hot stuff among in-memory databases - but mainly for complex (read: OLAP) queries.

In this article I explore whether DuckDB or SQLite is the better (read: faster) alternative for my simple queries.

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.