Copying a pmr::vector silently drops its allocator

A pmr::vector<int> looks like a value. It compares element by element, it prints like a vector, and b = a compiles without a murmur. Then you check where b’s memory actually lives, and it is not where a’s is.

original allocates from a stack arena. copy is copy-constructed from it, and the two compare equal. But copy does not use the arena. It fell back to the default resource, the global heap, and nothing warned you.

Why the allocator stays behind

For polymorphic_allocator, select_on_container_copy_construction returns a default-constructed allocator rather than a copy of the source’s. The standard treats the resource as salient state: it identifies which arena owns the memory, and that identity is not something a copy should silently inherit. So a copied container gets the default resource unless you name one explicitly, as in pmr::vector<int> copy{original, &arena}.

This is the crack in the “pmr is a drop-in” story. The three propagation traits (propagate_on_container_copy_assignment, _move_assignment, _swap) are all false for polymorphic_allocator, so the allocator is sticky: it stays with the object it was born on, through copies and assignments. A pmr::vector is a container with an identity, not a bag of values you can freely duplicate and expect the memory to follow.

The fix is small once you know the shape: whenever you copy a pmr container and want it in the same arena, name the resource at the copy site. The bug is that nothing makes you.

Sources: cppreference: select_on_container_copy_construction · Arthur O’Dwyer, “A not-so-quick introduction to the C++ allocator model”.