Comment by emtel
9 years ago
> Don't use anything from STL that allocates memory, unless you don't care about memory management.
I don't even know what to make of this. If you can't afford to use dynamically allocated memory at all, then there's nothing special about STL, you need to avoid all libraries that call malloc(). If you ask somebody why they are using `float* ptr = (float)malloc(sizeof(float) array_size)` instead of `vector<float> vec; vec.reserve(array_size)`, and their answer is "because STL is slow", run away. If someone complains about std::allocator being stupid, they have a point, but you still have a program that isn't going to write itself, and just because std::allocator is stupid does not mean that STL is categorically awful.
What is true is that you should understand the overhead of things like std::set<> and std::map<>, and how to get avoid that overhead when you need to, but this recommendation is basically a tiny subset of the recommendation "understand and use Modern C++".
> If you can't afford to use dynamically allocated memory at all, then there's nothing special about STL, you need to avoid all libraries that call malloc().
I think the idea (as seen in traditional high-performance C++ code) is to be very aware of allocations. Dynamic memory allocation is slow; sometimes, the slowest part of one's code. So it's fine to use a library that calls malloc() behind your back for small, occasional allocations (whether that library is the STL or libc or any of your other dependencies), but not in your inner loops, and not for your multi-GB data structures. Instead, manage your own buffers, size them right from the beginning using application-specific logic, realloc exponentially if you need to (but hopefully you don't need to), and use placement new to construct your objects in your buffer in a way to optimize access locality.