C++Now 2018

C++17 introduced the std::pmr framework. In this framework, a std::pmr::polymorphic_allocator＜T＞ holds a pointer to a std::pmr::memory_resource. The memory resource is in charge of managing and organizing the heap itself, and the allocator object is just a thin "handle" pointing to the memory resource.

This is not just a convenient implementation strategy for std::pmr! Rather, this elucidates the true meaning of the Allocator concept which has existed, unchanged, since C++98. An Allocator *is* a handle to a MemoryResource. Even std::allocator can — and should — be viewed as a handle to a global singleton "heap", and not as a MemoryResource in its own right.

From this core insight we derive many corollaries, such as the need for allocator types to be lightweight and efficiently copyable, the fundamental impossibility of implementing an "in-place" std::vector via stupid allocator tricks, and the philosophical underpinnings of "rebinding."

We'll show at least two non-standard examples of types modeling Allocator that act as different kinds of handles to heaps: a `shmem_allocator` that holds a `shmem_ptr` to a memory resource, and a `shutdown_safe_allocator` that holds a `weak_ptr` to a memory resource.

Time permitting, we'll
- discuss what we can expect from a "moved-from" allocator object
- relate the notion of "handle" to neighboring notions such as "façade" and "adaptor"
- suggest similarities between "allocator/heap" and "executor/execution-context"