And the issue with vector value initializing it's elements is also well known and programmers have been asking for a solution (more user friendly than a custom allocator) for a long time.
Want a vector that does not initialize its elements ? Ask and thou shalt receive: https://github.com/aguinet/pector
The whole point of C++ is to make it easy for people to write generic libraries beyond de standard base provided by the stdlib. So why won't you use those ?
Still it is fair to critique the specific tradeoff done by the standard library.
You do not have to pay for what you do not use.
What is unfriendly about custom allocators? Note that in this specific case you don't need to write any allocation function, you just have to re-implement the construct() function with something that does not value-initialises if no construction arguments are provided.
I disagree.
1. Everybody knows Python is a scripting language, and trying to do heavy computation without handing it off to a library is going to be slow.
2. A vector is the de facto data structure for this in c++. In Python, numpy is effectively the de facto approach for math.
1. "Everybody" knows that unordered sets/maps in C++ must de-facto use chaining due to the requirements imposed by the standard.
2. numpy.array is not part of the Python standard library. It is an extra component you still need to install separately. As someone who deals regularly with novice Python users (often coming from Matlab & the likes), one of the very first points of pain/confusion is the fact that I need to teach/convince them not to use the facilities of the core language to represent "vectors".
Also, IMHO tying allocation with initialization in the allocator concept is not one of C++ brightest moments.
There have been continuous talks about adding an unsafe_push_back and an unsafe resize for these and other reasons.
The same technique vastly improves map and set too.