> 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
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.
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).
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