1. The STL bakes in a bunch of assumptions about how the data structures you would want should work.
These assumptions are often wrong. It's possible they were not wrong when the STL was first conceived, but we don't care about that because we're writing programs now, not then.
For example the STL unordered_map thinks your hash map has buckets. After all, if you learned how to make such a data structure in a typical college course in like 1995 the hash map had buckets. So the mandatory API for the STL's unordered_map has buckets like in that college course.
But today in many cases you don't want buckets, you've got a single unbucketed structure. How do these APIs work with your better structure? They don't. The STL is incompatible with your better structure.
2. The STL bakes in a bunch of assumptions about how C++ works.
Those assumptions were undoubtedly correct when the STL was first conceived, but since then there have been major changes to the language and all it can do is bolt on more and more, and more boilerplate to try to cope.
Take emplace(). This looks like it's a better choice in a bunch of cases than say, insert() and then you dig into your STL implementation and you discover it had no choice but to construct your expensive object and then throw it away when it wasn't needed just as you might have with insert(). That's just how the class is defined, too bad.
If EASTL is in fact just an STL then it might be no better than a modern STL you got with your compiler. But some people choose to have something better instead of the STL. Abseil's Swiss Tables for example offer a faster Unordered Map, it's just that it isn't, and can't be, a std::unordered_map
The STL interfaces work just fine with your alternative hash map, for example, those from Abseil. But to get the speed that they got, Abseil had to impose restrictions that make it less general. So yes, it can't be an std::unordered_map. That's OK. The algorithm APIs work just fine on any class that looks like a standard container.
This is all messier because C++ didn't have Concepts at the outset and when it got Concepts those had to have duck-typing instead of having the programmer write down which types implement a Concept.
Both existing templates and any C++ Concept can accidentally implicate something as a duck (or a container) when it actually isn't. Meanwhile for an implementer, the only way to be sure you've written a working duck (or container) is to try it and see. You can't just assert "This is a duck" and have the compiler explain why it isn't AFAICT.
Even if Abseil's SwissTables weren't containers from the point of view of STL algorithms, the only way for Abseil to stop STL algorithms assuming they are anyway would be to purposefully sabotage the API and annoy users who don't need any such guarantee. So that sucks pretty badly IMNSHO.
When this is discussed there are usually two examples in play. One is ludicrous like Stroustrup's "CowboyWindow" from the 2nd edition of "The C++ Programming Language" which needs draw() for Window and draw() for Cowboy. This will be dismissed as a corner case that isn't going to have a real impact. It's hard to imagine some class that "accidentally" offers all the method signatures from your non-trivial concept when it's actually something quite different.
The other is the "backward compatibility" example. You have a better_map your company used for decades, and now some asshole came along and said it isn't a container because you didn't write that down? Who does he think he is?
But actually the problem you run into isn't CowboyWindow or better_map it's faster_map, which has exactly the same method signatures as better_map and so can be dropped in as far as the linker and compiler are concerned, but alas, for performance faster_map behaves a little differently and it must not be used as an STL container. Oops.
> but alas, for performance faster_map behaves a little differently and it must not be used as an STL container. Oops.
No one sane expects that every single implementation of an API must match the performance of its canonical implementation. Hell, I'm pretty sure that MS's STL in debug mode does not satisfy the STL performance requirements due to all the added checks, some being O(n) iirc.
Who said it was merely a performance difference? I said it was a behaviour difference for performance.
Both C++ concepts and templates have cat rules, "If it fits, I sits". Your insert() method has different semantics? I don't care, the function signature matched so I'm calling it anyway.
The STL is meant to solve a fairly general class of problems. It isn’t optimized for a number of use cases, and frankly some of the design and nomenclature is terrible.
This is now a classic reading:
(tldr: it is faster to call PHP process from C++ code and do regex in PHP than to use std::regex, and slow std::regex will never change because the Comittee doesn’t want to break ABI in favor of speed):
