I've always hated this bit of conventional wisdom, which has become less and less applicable over the past couple decades. STL implementations are now quite highly optimized within their spec. With the one little caveat that they're generally optimized for CPU cycles rather than per object memory usage.

But you should understand the performance characteristics of the STL. A std::vector is super fast for basically everything except for dynamic resizing. If performance is a concern, your first approach should be to see if you can avoid reallocation. Often it's very simple to just preallocate a reasonable maximum, or calculate an exact maximum based on your input.

Finally, if you truly need to do weird stuff with resizing, you can look at other containers or write your own.

> std::vector is super fast for basically everything except for dynamic resizing.

Resizing it is just fine, there's not really anything unexpectedly slow there. Rather, the big downside to std::vector is the lack of small size optimization (something std::string has, so too does std::function for that matter).

That's the big win for things like absl's inlined_vector https://github.com/abseil/abseil-cpp/blob/master/absl/contai...

It's an ABI break to add small-size optimizations to std::vector at this point so unfortunately while there's not really anything in the API requirements that would prevent it, compatibility concerns pose a formidable barrier

> It's an ABI break to add small-size optimizations to std::vector at this point so unfortunately while there's not really anything in the API requirements that would prevent it, compatibility concerns pose a formidable barrier

It's also a tradeoff as you would either need additional branching on access (this is what most std::string implementations do) and/or bloat the size of all vector objects, even those that will never fit into the static size.

It's a tradeoff the user can make, not something the STL needs to generically know like std::string does. If you look at inlined_vector (or similar implementations), the static size is specified in a type parameter, not something automatic. So just have it be 0 if you want it to behave like std::vector does currently. As such, no downsides to adding this to the type other than the ABI breakage. Default the size to 0 and you preserve API compatibility, even.

I thought the conventional wisdom was to avoid the STL if you need consistent performance across platforms, because they all have different pitfalls. Things might be different with libc++, now, though, since you can use it in most cases.

My point exactly: I can trust the STL’s standardised interface, but performance is often dependent on implementation details, which are bound to vary from platform to platform, or even from computer to computer (assuming a dynamically linked libc++).

On the other hand, if you’re not at the point where you care about maximum performance, you may want to shy away from C++ altogether.

This implies that there are very few situations in which C++ with STL is the right choice - which seems contrary to how widely it’s actually used.

This seems like a pretty silly way to look at performance - If I'm working in C++, I 'care' about performance, but performance always exists on a continuum.

If I "truly cared" I could write it in assembler; but I don't, because chasing down the diminishing returns isn't worth it.

C++ w/STD is a perfectly valid (and extremely powerful!) point in the continuum that runs from Python to Assembly :)

Hmm, I’m not sure I agree there. There’s a difference between using C++ because I just want to avoid obvious waste (interpreter, GC pauses…), and actually optimizing my code.

I would put v.empty() vs v.size()==0 in the latter category. Day to day, I mostly trust that std::vector is not wasting cycles except on resizes.