Polymorphic Memory Resources in C++

In a Nutshell

It is a best practice to reserve memory beforehand for all the STL containers so that their expansion is accounted for. However, sometimes it is extra effort to compute how much a resouce will take up in memory at a certain point. Either because we do not know or, in many cases, because we will have to process the whole data just to know how much we have then reserve memory for it and read it twice, this time to commit changes.

For many cases, the best solution is to define a plateau for the memory pool we are using and account for failures if we surpass the estimated amout, either by adjusting it via benchmarking or puting a limit on how much data is to be processed in the first place.

In C++ we have what we call pmr versions of the standard STL containers. They are a handy syntactic sugar to use std::pmr::polymorphic_allocator as an allocator for the containers. Which defines the buffer where we store the objects with the intention of localising the memory used by the containers instead of having it spread aroung all over the place.

Use case

If we are reading from a stream and we do not know the amount of the data, it is better to avoid buffer overflows or running out of system memory, and instead use monotonic buffer with a prefixed buffer size depending on the task.

In case we wanted the buffer to grow when exceeded, we should omit std::pmr::null_memory_resource().

const std::size_t buffer_size = 16384; // 16 KB
auto buffer = std::make_unique<std::byte[]>(buffer_size);
std::pmr::monotonic_buffer_resource mbr{buffer.get(), buffer_size, std::pmr::null_memory_resource()};
std::pmr::polymorphic_allocator<std::uint32_t> pa{&mbr};
std::vector<std::uint32_t> stream(pa);
try {
    // process data into the stream
} catch (std::bad_alloc e) {
    // no need for cleanup since the buffer owns the memory
}

Conclusion

Knowing how much memory we have allocated is always a good idea, setting an upper-bound on how much memory we would ever have is a great idea, especially in embedded systems and microservices where resources are limited.