CppCon 2019

The C++ standard library has supported custom allocators for as long as C++ itself has had a standard. Support for plugging in custom allocators has improved with each release, culminating (so far) in the 'pmr' allocator model in C++20 (with significant support in C++17). The substantial performance benefits of use of allocators (when used appropriately) are well-documented. Moreover, there are a variety of collateral benefits to clients -- such as rapid prototyping of alternative allocation strategies -- that make their use even more compelling. Still, the real-world costs associated with orchestrating the integration of allocators throughout a code base, including training, supporting tools, enlarged interfaces (and contracts), and a heightened potential for inadvertent misuse cannot be ignored. What's more, despite strong motivation to support allocator usage uniformly, there are corners of the C++ language (e.g., aggregates, lambda expressions, compiler-generated constructors) where the grammar simply doesn't admit them. Those that put up with these substantial cost and annoying inconsistencies do so because the need the manifest value that only allocators can provide, while others make due without.

But what if there were some feasible way to eliminate most of the real-world costs, leaving all the benefits to be enjoyed by everyone if and as desired? What would the skeptics say then?

In this session, Alisdair Meredith and Pablo Halpern will delve into the issues holding back widespread use of allocators, and present some ground-breaking ideas on how the language itself might move forward, making custom allocator support transparent in the majority of cases. We will discuss our ongoing work exploring this language-supported memory-allocator design space, including early experiments with the GCC and Clang compilers, and finally speculate on possible benefits to important areas of C++ beyond memory allocation alone.

Although not a prerequisite, we recommend attending John Lakos's talk "Value Proposition: Allocators-Aware (AA) software", given earlier in the week.