Hacker News Reader

Comment by colinmhayes | Hacker News Reader

Is this really necessary? How many implementations of the standard library do we need? I get the feeling that engineers love reinventing the wheel so much that they forget to ask themselves what's wrong with the current wheel. My last company had its own implementation of the stl and it was a piece of crap, productivity would've gone way up if we just used the normal implementation and boost threading. Maybe I'm just projecting, but I get the feeling this company wasn't the only one that has made that mistake.

View on HN

EA and Bloomberg happened to make similar extensions to the standard library. Then, when the C++0x revision started, they both submitted proposals explaining their extensions including why they felt the extensions were necessary ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... , http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n446... ). The approach eventually made it into the standard ( https://en.cppreference.com/w/cpp/memory/memory_resource ).

Their docs clearly explain the difference and why this implementation exists, and reasons to use (and not use) EASTL: https://eastl.docsforge.com/master/faq/#info2-what-uses-are-...

Full disclosure: I used to work at EA and while I was there I contributed a tiny amount of code to EASTL.

EASTL provided a bunch of value that the standard STL would not. The biggest benefit was a unified implementation across all platforms. Standard library STLs all had their own idiosyncrasies and code that worked on one platform might not compile, or worse, have a bug on another.

At the time, EASTL was equal or higher quality than standard implementations. Performance was better, code quality was better, and it broke from the standard in some key ways that were important for performance, and it had some key upgrades that allowed usage patterns and data structures that the standard STL simply didn't allow:

Vectors supported "trivial relocation" before the existence of move constructors. While move constructors have ameliorated the problem, I argue that feature is still missing from c++. Please support P1144! http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1144r5....

Intrusive containers (in particular, intrusive linked lists in eastl::intrusive_list) embed the container overhead into objects themselves. This allows non-movable objects to be stored in these lists without requiring an extra pointer dereference on access. It also lets you convert an object reference into an iterator over the list that contains it. There are tons of uses for this. It also allows polymorphic lists (e.g. intrusive_list<BaseClass> that actually holds instances of various subclasses, again without an extra pointer dereference)

If you want more information, EASTL's lead programmer Paul Pedriana (rip) goes into detail in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...

Every C++ shop that I've worked in has done the same thing.

I suggest watching this talk:

https://www.youtube.com/watch?v=vElZc6zSIXM

Or pretty much any other by Chandler to understand why the STL sucks and why you should write better datastructures for your own use cases.

All nice and good if one is a compiler expert, except most people end up writing datastructures that perform worse than STL.

It was probably made in the stone age sometime in the 1990's.

The STL is problematic and not a great solution for a lot of things, so replacing it with something else is very common practice.

Could you show how it is problematic? And why replacing it with this one is better?

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.

What design nomenclature is terrible? Any examples?

unordered_map is a terrible name for a hash map, imho.

Awkward perhaps but not terrible. It emphasizes the one quality that makes it different from std::map.

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):

https://cor3ntin.github.io/posts/abi/

std::regex feels like a very bad joke. C++, the great AOT performant language, whose regex can be beat 10x by any interpreted language.

Reply on news.ycombinator.com