Recently, I was once again on CppCast, and once again[1], I talked about Catch2 and C++'s standard library support for random numbers. One of the things I said was that random distributions are not one-size-fits-all. This post is about how this applies to Lemire's algorithm, which is the state of the art for generating uniformly distributed integers in specific intervals. Introduction In C++, <random> separates the concern of generating random numbers between Random Number Engines, which generate integers in some predefined range, and distributions, which turn these into other numbers in ..read more

std::vector is often said to be the default container. This is because it provides a simple abstraction over a growable contiguous chunk of memory, thus providing good baseline performance for common operations, such as adding more elements or iterating over them. However, many non-standard reimplementations of std::vector have emerged over time. These are usually driven by performance consideration, e.g. avoiding allocations for small vectors[1], having static capacity[2], tightly integrating with the OS for faster reallocations[3], or optimizing moving elements with bitwise copying[4]. Most ..read more

At the end of January, I removed some low-hanging allocations from Catch2. This meant that running the SelfTest binary made 8k fewer allocations with v3.3.1 than with v3.3.0. Unbeknownst to me, it also made section tracking in v3.3.1 ~4x slower. This post is about how that happened and what I/you should learn from this. Let's start at the beginning. The beginning As I already mentioned, I decided to work on the number of allocations in Catch2. This was motivated by this topic coming up at work[1] and by looking at Snitch, which is a test framework that provides API similar to Catch2's but with ..read more

Due to maintaining Catch2 and generally caring about SW correctness, I spend a lot of my time thinking about tests[1]. This has left me with many opinions about tests, some conventional and some heterodox. Originally I wanted to make a lightning talk out of these, but I won't be giving any this year, so instead, I wrote them up here. And since this is a blog post, I also have enough space to explain the reasons behind the opinions. Unit test opinions Note that the list below is in no particular order. I added opinions to the list as I remembered them. You should be using Catch2. Okay, I am n ..read more

There is a lot of confusion about floating-point numbers and a lot of bad advice going around. IEEE-754 floating-point numbers are a complex beast[1], and comparing them is not always easy, but in this post, we will take a look at different approaches and their tradeoffs. Note that this whole post assumes binary IEEE-754 floating-point numbers. There are more different types of floating-point numbers, e.g. IBM likes decimal floating-point numbers enough to support them in hardware. However, most of the text below should be applicable to different representations too. Floating point basics I do ..read more

This post will go over testing with Catch2 and will be very example heavy. I want to cover first the basic usage of Catch2 (tests, assertions, sections, test grouping) and then some more advanced and less used features. I will not cover every feature Catch2 has, just those that I think are most likely to be generally helpful. Note that this post is not about the whys, hows, and whats of testing. I intend to write a post about that too, but this one exists to show off Catch2. All examples in this post will be written against the v3 branch of Catch2. Catch2 basics As with all testing frameworks ..read more

At some point, we have all heard a quote attributed to Donald Knuth, saying that: Premature optimization is the root of all evil There have been many fights over whether this applies, when is an optimization premature, and so on. This post is not meant to participate in these fights[1], but I do want to quote Donald Knuth in full before continuing: Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered ..read more

The Little Things is a new series of posts based on Locksley's internal training sessions. Often the contents are either proprietary (e.g. the inner workings of specific master key platforms) or not generally interesting (e.g. our internal libraries and tooling), but sometimes the contents are suitable for a wider audience, in which case I want to share them. This post will be about some source-level techniques for speeding up C++ compilation, and their (dis)advantages. It will not talk about things external to C++, such as buying better hardware, using a better build system, or using smarter ..read more

Last week I wrote about the various problem with using C++'s standard library (mainly <random>) to generate random numbers. This week I will outline what I think are the (standardizable) solutions to fix the functionality in <random>[1] and make it widely usable. The content of this post is based on the three C++ standardization papers I presented in Prague, P2058, P2059, P2060, and various conversations I had afterwards on the same topic. Now, onto the solutions themselves. Fixing std::random_device In my last post, I complained that std::random_device is allowed to be not random ..read more

Recently I found myself once again writing a long forum post about the problems with standard-provided random number generation facilities (both C++'s <random>, and C's rand) in C++. Since I keep writing these, I decided to write it all down into one blog post so that I can link it to people later. This is that blog post. A quick summary of this post would be "Using C++'s standard library for random number generation is a bad idea, and you should either roll your own, or use an existing library. I recommend C++ PCG utilities, or, if you already use Boost, Boost.Random". Now, onto the act ..read more