Exploring Hourglass APIs in Rust

There are two talks on APIs that I think every programmer should watch, learn, and study from: Designing and Evaluating Reusable Components from Casey Muratori. This absolutely wonderful talk is the fundamental source for how to design APIs. Hourglass Interfaces for C++ APIs from Stefanus Du Toit. This talk discusses having a rich API for users that is backed by a C API into proprietary code. These two talks give a really good and grounded lesson on fundamental API design - the choices you make and the ramifications they can have.

Introducing hashmap.h

I asked on twitter the other day whether anyone had a hashmap that could work with string slices - parts of a string that are not null-terminated and thus have to have an explicit length to accompany the pointer. I didn’t get any responses on this so I commented with a follow-up that I had grabbed some code written a few years back by the awesome Pete Warden of Google fame, and morphed it into what I required:

Asynchronous Reading in subprocess.h

One hotly requested feature for my single header C/C++ process spawning and management library subprocess.h was the ability to read from the standard output or error of a spawned process while it was still executing. In this PR I’ve added support for this, but it requires some change of behaviour in your code if you want to use it. C FILE’s and Asynchronous Reading I use a really clever hack to give my users a standard C FILE handle with which they can read the standard output and error, and write to the standard input of any processes they spawn.

Adding fixtures to ubench.h

One thing that was missing from ubench.h (intentionally to keep the initial code drop simple) was fixtures. In this PR I’ve added them. So what are fixtures and why should you use them? What are fixtures? Fixtures are a way to setup and teardown state that doesn’t contribute to the timing of the actual benchmark itself: // First you declare a struct that contains the state you need. struct foo { unsigned size; char* foo; }; // Then you setup the benchmark state - using the ubench_fixture implicit field.

I’m now 99% Confident in ubench.h

So I recently created a new single header C/C++ library for benchmarking your code - ubench.h. It’s funny how as soon as you push something public you realise all the flaws in it - but that’s fine! Software (like people) should grow and develop as it gets older. The way I was trying to gauge the accuracy of the result from multiple benchmark runs was somewhat… broken. In this PR I’ve switched to using a confidence interval, and I’ll now explain why.