"zero overhead abstractions" is a principle of the language, not the library. The STL containers are clearly designed to be on the "safer" side than the performant side. You are right that, perhaps, we've extracted the wrong lesson from the STL but your version ("iterators everywhere, including for your own algorithms and container types") is still definitely the right message.

As an example, STL unordered-maps have fairly strict requirements around iterator invalidation and that results in indirection that do affect performance. It's pretty easy to make a "faster" unordered_map that tosses that requirement (as many do).

> Most high performance projects use vector and little else.

Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since.

[1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place.

[2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...

> string-to-hash map

string-to-int hash map

Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.

The motivation for creating of EASTL was mostly to get rid of allocations. std::vector does not have an allocation problem. Other STL containers do.