pmr
Part of the wro.cpp pmr series — 8 of 8 posts published so far.
std::pmr is one abstract class with three functions
The whole std::pmr framework is one abstract class, std::pmr::memory_resource, with three functions to override: allocate, deallocate, is_equal. A dozen-line logging resource shows a pmr::vector's allocations, then a monotonic_buffer_resource placed in front of it collapses them to zero. Episode 1 of the pmr series.
A pmr::vector on a stack buffer never calls new
The HFT and game-loop promise of pmr, made testable: override operator new to count heap allocations, then fill a pmr::vector from a monotonic_buffer_resource backed by a stack buffer with null_memory_resource upstream. Ten thousand pushes, zero heap calls. Episode 2 of the pmr series.
Does custom allocation still pay off in 2026?
Custom allocation used to buy 44 percent. A 2026 re-run of the classic study finds modern allocators like mimalloc have closed most of that gap, so a pmr arena now earns its place for predictable latency and fragmentation resilience rather than raw throughput. With a live allocation-count demo. Episode 3 of the pmr series.
Copying a pmr::vector silently drops its allocator
A pmr::vector looks like a value type, but copy construction does not copy its allocator: select_on_container_copy_construction returns the default resource, so a copied container silently allocates from the global heap. The propagation traits make the allocator sticky. Episode 4 of the pmr series.
Move-assigning pmr containers across arenas deep-copies
Move assignment should be an O(1) pointer steal. For pmr containers with different resources it cannot steal the buffer, so it allocates in the destination and copies every element, turning a move into an O(n) copy the type system cannot warn about. Episode 5 of the pmr series.
The pmr crash is the buffer that died first
The most common pmr crash rarely comes from a custom resource; it is lifetime. The container deallocates back into its resource on destruction, so the resource must outlive it. A live demo shows the destruction order and the declaration-order rule that keeps it correct. Episode 6 of the pmr series.
Making your own type allocator-aware needs a second constructor
Put a pmr::string inside your own struct and it will allocate from the default resource unless the struct is allocator-aware: an allocator_type, an optional allocator argument in every constructor, and forwarding to members. This is uses-allocator construction, shown reaching a string nested in a pmr::vector. Episode 7 of the pmr series.
WG21 now says new library types must ship a pmr alias
The worry that pmr is a C++17 experiment the committee abandoned is backwards. WG21's 2024 policy P3002 makes pmr the default vehicle for new allocating types, P1083 brings resource_adaptor in C++26, and P3153 makes optional allocator-aware. A live resource_adaptor demo bridges a classic allocator. Episode 8 of the pmr series.