joaquintides

Abstract: Many people hate math, some programmers do too. We hold that this hate stems from a reductionist view of mathematics as merely rule application: number crunching, equation solving and the like. But programming is more akin to mathematical creation, and writing a well designed, neat program can be as exhilarating as devising a new little math theory. In this talk we'll investigate how the mathematical mind approaches the world, and how developing a mathematical inclination can help you be a better C++ programmer. Presentation: https://github.com/joaquintides/usingstdcpp2026

Vinnie Falco, creator of Boost.Beast, shares the origin story behind two new coroutine-based networking libraries, Corosio and Capy. While designing Beast2 as a C++11 networking library, Falco repeatedly sought design advice from Peter Dimov, who had one persistent answer: just use coroutines. Determined to prove him wrong, Falco set out to learn coroutines, implement his own task type, and benchmark it against ASIO.

The results surprised him. Initial benchmarks confirmed his suspicion that coroutines performed poorly, but after applying optimizations like a recycling allocator, performance improved dramatically. Under more realistic, higher-abstraction scenarios, coroutines actually beat ASIO - because composed operations built from nested operation states accumulate costly move constructions and memory copies as structs grow, while a coroutine handle remains just a pointer. What began as a mission to discredit coroutines became the foundation for two new libraries.

https://github.com/cppalliance/corosio https://github.com/cppalliance/capy

Levers that matter: Backend: std::vector (default) or boost::container::small_vector for small buffer optimization and fewer heap hits. Block: choose an unsigned type that matches your CPU/cache tradeoffs (e.g., 64-bit on x64). Maintainability: API stays the same—operator&, |, ^, shifts, resize/shrink_to_fit. Add reserve for predictable growth.

Boost.Decimal by Matt Borland and Chris Kormanyos has been accepted! Implementation of IEEE 754 and ISO/IEC DTR 24733 Decimal Floating Point numbers. Thanks to Review Manager John Maddock.

Repo: https://github.com/cppalliance/decimal

Docs: https://develop.decimal.cpp.al/decimal/overview.html

Abstract: Push and pull are the two main paradigms when it comes to data processing. In this talk, we'll discuss both approaches from an abstract point of view, compare them for expressivity and efficiency, review some prominent C++ examples and propose a push-based approach that outperforms C++ ranges, sometimes by a wide margin. We end the talk by discussing how coroutines blur the boundaries between push and pull and what it would take for them to be a compelling option for high-performance data processing.

Presentation and associated material:

https://github.com/joaquintides/usingstdcpp2025

Iteration has been improved since, and now we’re beating Abseil on iteration plus erasure:

https://github.com/boostorg/boost_unordered_benchmarks/tree/...

Unlike regular hash functions, so-called perfect hash functions guarantee that no collisions ever happen, that is, every two distinct keys map to different hash values, which allows for the construction of hash tables with strict O(1) performance. This seemingly impossible feat comes with the tradeoff that the set of elements must be known in advance prior to table initialization. In this talk we'll review the basics of perfect hashing theory, explain some of the most common algorithms found in the literature, review some C++ perfect hashing libraries and learn how perfect hashing can be used to improve the efficiency of our programs.

Video: https://youtu.be/yOo6GnbKzp8

Presentation: https://github.com/joaquintides/usingstdcpp2024/raw/main/Per...

Repo: https://github.com/joaquintides/usingstdcpp2024

Boost 1.81 (Dec 2022) released boost::unordered_flat_map, a hashmap (unordered associative container in C++ parlance) that relies on open addressing and SIMD techniques to provide extremely high performance. In this talk, Joaquín will invite you to look under boost::unordered_flat_map's hood with him and learn about this container's data structure, its key design elements and how it compares with other top-performance C++ hashmaps both in theory and in practice. The talk finishes with a teaser on concurrent hashmaps arriving as part of your Boost update later this year.

Complexity is still O(n) because sizes grow exponentially, so the cost of amortizing rehashes over the number of inserted elements is a constant. Here's a theoretical analysis of this: https://www.cs.cornell.edu/courses/cs3110/2011sp/Lectures/le...

Hi Veedrac, some results at

https://news.ycombinator.com/item?id=10177262

Thanks for the link. The inorder_next you refer to is equivalent to my increment (even the structure of the code is the same) with the difference that inorder_next relies on 1-based indices and uses intrinsic ffz. Definitely worth a try.

Hi, I totally agree with you analyzing the assembly produced can provide lots of insight. For the particular case of understanding cache friendliness, though, I'm not so sure looking at the assembly can help that much, since caching manifests itself ony at run time. One has to learn about it in indirect ways via measuring.

You might also consult the entries given below, which take into account some late improvements in Boost.MultiIndex not present at the beginning of the series:

http://bannalia.blogspot.com/2014/01/a-better-hash-table.htm... http://bannalia.blogspot.com/2014/01/a-better-hash-table-gcc... http://bannalia.blogspot.com/2014/01/a-better-hash-table-cla...

As you correctly point out the problem is entirely symmetrical to that of keeping a hot beverage as hot as possible. If we take the different problem of trying to cool a hot beverage, the optimum, pathological solution would be a glass with 0 height and infinite width --studying this problem with the additional constraint that width be limited to some predefined value might make for an interesting followup article.

I've added a small postscript explaining why calculus of variations (in its simplest form at least) is not applicable to this problem.