[smarx007]

Isn’t polymorphic memory allocator the most significant recent C++ addition for embedded systems that allows preventing runtime memory allocation after the init phase and thus allows conformity to MISRA and other guidelines for critical SW development (esp. when using stdlib)?

[jeffbee]

You could always run your stl with your favorite allocator. PMR just makes it simpler to use, and provides library implementations of common allocator patterns. PMR is not a zero-cost abstraction, though. Its implementation via type erasure has performance costs.

[einpoklum]

> Isn’t polymorphic memory allocator the most significant recent C++ addition for embedded systems

I would say no. Run-time polymorphism is overrated IMHO, and more so for embedded systems, again IMHO. C++ in general has been moving towards preferring things happening statically rather than dynamically.

> that allows preventing runtime memory allocation after the init phase

That's not what allows preventing runtime memory allocation after an "init phase". Unless I'm misunderstanding what you mean.

... oh, I think I get it: As a general rule, avoid using standard library data structures with allocators. They may work fine as boilerplate, but are usually not what you want when you have any non-trivial requirements. std::vectors are fine if you don't mind the allocations - but you do, so not even those. You could use custom allocators, but that whole mechanism is totally broken design in the opinion of many; see Andrei Alexandrescu's talk about this subject: https://www.youtube.com/watch?v=LIb3L4vKZ7U

[BenFrantzDale]

I think polymorphism has its place, and Lakos’s use of them for allocators is one such place: it lets you bind a well-defined interface to a concrete implementation at runtime. So rather than wrestle with templated allocators where every `std::vector` is a different static type, you can use `std::pmr::vector` and at a small runtime cost have huge runtime flexibility that (according to Lakos) can easily pay for itself.

[einpoklum]

Granted, std::pmr::vector has its place...

but - PMR allocators also have that weird fixation on types, which they should not; plus, dynamic allocation is expensive. It's particularly expensive to let your containers do reallocation willy-nilly on their own. I'd go with `std::array`, if I wanted something dynamic - a dynarray (which the standard doesn't even have).