The work of one obsessive author, who never gave a good explanation for why the thing needed to be in the standard library instead of an external one. The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint. So eventually they relented. Outside coverage I have seen so far seems to be to the tune of "WTF is this weird thing?" and quickly glosses over it.
I wonder if it's going to end up like the export keyword.
I feel like std::hive fits right in to the C++ stdlib group of collections
The least stupid is std::vector which is just the typical O(1) amortized growable array type found in most modern languages, with a mediocre API. 8/10 could do better.
std::array is just the built-in array type C++ should have but doesn't. This shouldn't be a library type, that's embarrassing.
std::deque looks like you're getting something like Rust's VecDeque but you aren't, it's a weird hybrid optimisation which presumably made sense on some 1980s hardware. I asked STL once to explain what it's even for and they didn't know. [[For reference STL is the name of the guy in charge of Microsoft's implementation of the C++ standard library, Microsoft also calls that library STL for reasons we needn't address]]
std::list is the extrusive doubly linked list. This type makes sense in a DSA class. Why is it in the C++ standard library? I dunno, maybe C++ is intended only as a teaching language?
std::forward_list is the extrusive singly linked list. You know, for a different seminar in that same DSA class. You might want the intrusive linked list, you don't want this.
std::map and std::set are probably red-black trees. OK, you might need those and for some reason not care about the details (which aren't specified here)
std::multimap and std::multiset are even less obviously useful. I have never seem them used in real software. Why are they in the standard library?
std::unordered_all_of_the_above_maps_and_sets look like the simplistic hash table you'd be shown in an intro DSA class either taught by somebody who doesn't know the subject well or aiming to cover the basics and get back to their research. This will perform poorly on any hardware with features like a cache.
The C++ stdlib carries broken garbage basically indefinitely. C++ doesn't have the same library stability promise that Rust has, but in practice stuff that nobody cares about is never removed.
That std::hive will fit right in. Another container type you probably shouldn't use, draining precious maintenance resource from groups who have better things they could be doing.
> These are in the standard library because someone proposed their inclusion.
As with std::hive. Indeed the "unordered" containers, just like std::hive were repeatedly knocked back and eventually got in decades after they were obsolete. Persistence really does pay off in C++
> They're fine for the majority of people who really don't want to roll their own data structures each time.
Sure, doubtless std::hive is fine for that same majority of people.
>The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint.
That's a mean interpretation, mean both towards the committee and towards the author.
The work of one obsessive author, who never gave a good explanation for why the thing needed to be in the standard library instead of an external one. The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint. So eventually they relented. Outside coverage I have seen so far seems to be to the tune of "WTF is this weird thing?" and quickly glosses over it.
I wonder if it's going to end up like the export keyword.