The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms).

Many high performance projects use vector but few other containers.

If the STL had a lesson to teach us it should have been "iterators everywhere, including for your own algorithms and container types." Instead most people learned "C++ has all the containers you need built in, throw away your performance tricks and let it call malloc a million times."

"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.

C++ the language, maybe.

STL really is a cruel joke.

is it ok to mutate a data structure while an iterator to it is live? It depends, which makes it much less abstract and generic than it could be (and that people believe it is)

Error messages are useless. Compilers can and do (recently) help with that, but the main issue is the convoluted STL design in which every instantiation’s type name actually takes a full 80x25 screen to spell out.

STLs primary objects are individual iterated elements, which does abstract over pointers (as was stepanov’s intention) but are at such a low level of abstraction as to be onerous.

Modern C++ is slightly better.

Could be true, but a modern language such as Rust has its own problems:

https://news.ycombinator.com/item?id=16442743

What you’ve just linked to is a solution to the issue mentioned above. Rust makes a lot of guarantees, but sometimes those guarantees run afoul of certain required operations in different contexts. For this reason the language has an escape valve, unsafe, and the unsafe blocks are blindingly obvious in the code.

To say it’s a problem is misleading at best.

STL tried hard to abstract pointer manipulation semantic of low-level C and apply it everywhere whether it fit or not. This pointer heritage inevitably lead to misfeatures like invalidation of iterators under container mutations or the need to have access both to the iterator and its container to implement things like vector::erase().

Other languages and runtimes use the notion of an iterator or cursor that is alone enough to perform all looping-like operations on the container including efficient erase() and can cheaply (so it is ok to have that in production) or even with good optimizing compiler at zero cost provide protection against container mutations.

I have recently got upto speed with c++17 features and I want to explore more C++. So far I have used Java and Python to build webapps. Are there libraries/framework that can replicate the MVC in C++ as well? I think I can extend functionalities from there.

Not quite MVC but RxCpp exists and can help with designing MVP style code. (also known as event driven programming)