But the criticism is still questionable: an allocator can define ::construct() not to do anything, and leave actual construction to user code.
A few more of the criticisms are addressed in C++11 which fully support stateful allocators; they were not mandated (but still allowed) in C++03 because some implementors felt that the STL was too much work to implement already.
Most of the rest are QoI issues, and it is perfectly reasonable for EA to have its own STL implementation that give the same guarantees across platforms, but it is not a criticism of the standard itself.
Be careful that 'trivial' is a term if art in the context of C++ initialization. Having to do work is different than not having to do it. Constructting a vector of N optionals is O(N) as opposed of a vector of a truly trivially constructible type, which is O(1) (although I'm not 100% sure if the standard guarantees it or it is just a QoI).
But the criticism is still questionable: an allocator can define ::construct() not to do anything, and leave actual construction to user code.
A few more of the criticisms are addressed in C++11 which fully support stateful allocators; they were not mandated (but still allowed) in C++03 because some implementors felt that the STL was too much work to implement already.
Most of the rest are QoI issues, and it is perfectly reasonable for EA to have its own STL implementation that give the same guarantees across platforms, but it is not a criticism of the standard itself.