I really wish someone takes the work of ditching the STL as a whole and make an unofficial “version 2” of the same standard library. I mean, IO sucks ass, std::string really sucks, containers like unordered_map are really slow (because of the pointer stability requirements), custom allocators are cumbersome, the regex library is a mess, why are string_view and span different things, yada yada. (And darn those long compile times and horrendous debug-mode performance!)
> IO sucks ass, std::string really sucks, containers like unordered_map are really slow (because of the pointer stability requirements), custom allocators are cumbersome, the regex library is a mess, why are string_view and span different things
EASTL still adheres to the same API as the proper standard library, doesn't it?
Anyway, API-wise, you at least have ranges in C++20, which affords you some syntactic convenience in the ability to pass ranges rather than pairs of iterators. But I definitely agree that both form-wise and impl-design-wise, a change would be welcome.
CERN and HEP (high energy physics) in general care more about HTC (high throughput computing). In general, event processing is pleasantly parallel since each event can be processed independently of others. A lot of the computing is really similar to a world wide distributed map reduce cluster. This significantly reduces a lot of the complexity that comes up when working with a workflow that might have thousands of threads interacting with each other.
There are dozens of hash map implementations for C++, and while they all have O(1) asymptotic complexity, the runtime performance can be vastly different depending on the implementation choices. The design space of a hash based data structure is immense, but std::unordered_map is generally always avoided unless your main goal is either ease-of-use or beginner-friendliness or you simply don't care about performance. But if any of these is true for your context, then C++ is probably not the right tool for the job anyway.
In many cases C++ is the only tool for the job, unless one wants to have fun doing their own toolchain on top of the platform SDKs, or drop down to C, even worse.
Basically, something like a more updated version of EASTL (https://github.com/electronicarts/EASTL) might be really useful.