3 ms·

It's C++. Its goal is speed over all else. So it tries to carve out space for where the optimizer can assume lots of things are true. Since they don't use anyth

It's C++. Its goal is speed over all else. So it tries to carve out space for where the optimizer can assume lots of things are true. Since they don't use anything like Hoare logic they have to get their assertions from somewhere else, inferring them as follows (among other things): Undefined behavior just means that the specification does not say what will happen--so you can't rely on it as a user. The upside is that the compiler (and the compiler writers) can assume that places where the undefined behavior would occur in your program cannot be reached in practice--and thus optimize your program better. STL, which these containers are part of, is famously speed-optimized. STL (like C++) was designed for speed first (if at all possible then zero-cost abstractions) and thus does very little error checking on its own. Also, C++ is compiled ahead of time--so whatever optimizations it wants to make it has to do BEFORE it starts the program. That means it cannot adapt to the concrete runtime circumstances on the fly (like Java can) and so they have to keep even the worst case runtime down in everything they do. If they did check whether the thing is empty beforehand then that would cause a slowdown (at least that's the idea--better measure it), mostly because now there would be a branch in the first place. Hence they avoid doing that.

pjmlp 4y ago
Yet we get stuff like std::regex, the speeding train of regular expression parser engines.
- Gibbon1 4y ago
  My theory is the compiler maintainers don't themselves use 90% of the language features they implement. So they can't begin to care how well they work for people writing other types of software.
kllrnohj 4y ago
> STL, which these containers are part of, is famously speed-optimized. STL (like C++) was designed for speed first (if at all possible then zero-cost abstractions) and thus does very little error checking on its own. Only kinda? A bunch of the containers then make other promises or leak details that prohibit meaningful optimizations. An extra branch in std::vector::pop_back() is such a pointless savings compared to, say, that std::map is basically mandatory red-black tree or that std::unordered_map must store elements in a linked list to preserver iterators across removals. Like almost none of the containers in the STL are "fast" at this point. std::vector is probably about the best, but even it is missing small-size optimizations (and that's ignoring the hair-brained bool specialization that then breaks everything)
- tialaramex 4y ago
  I had once assumed std::unordered_map was from the original Standard Template Library (which pre-dates C++ standardization), but turns out (I was told in a r/cpp thread) it's more modern. In 1998 std::unordered_map would have been an excusable design mistake, domain experts knew in 1998 that's a sub-optimal design for this dict / hashmap structure - but you could suppose perhaps they were not on the committee. In 2011 it's not an excusable mistake, better structures are widely known in academic and in industry - it was an unforced error. The more closely I look at it, the more I'm convinced that unsafety wasn't an inadvertent and undesirable consequence of a "must go fast" mindset in standard C++, unsafety was the whole point. It makes me think about that speech by Susan Sarandon's Rick & Morty character, Dr Wong. Dr Wong: "I have no doubt that you would be bored senseless by therapy, the same way I'm bored when I brush my teeth and wipe my ass, because the thing about repairing, maintaining, and cleaning is; it's not an adventure. There's no way to do it so wrong you might die." Software Engineering is an engineering discipline, it is not supposed to be an adventure. Programming C++ is an adventure, you can do it so wrong you might die. We should stop paying people to go on an adventure, let them do that exclusively on their free time if they want.
  - gpderetta 4y ago
    hash_map was indeed part of the original STL, but was not standardized in C++98. It was still widely available, in slightly incompatible forms, as an extension. In C++11 it was standardized with only minor changes (and renamed). The address-preserving property, which precludes an optimal implementation, was considered important to be a near drop-in replacement of std::map.

pjmlp 4y ago

Yet we get stuff like std::regex, the speeding train of regular expression parser engines.

Gibbon1 4y ago
My theory is the compiler maintainers don't themselves use 90% of the language features they implement. So they can't begin to care how well they work for people writing other types of software.

kllrnohj 4y ago

> STL, which these containers are part of, is famously speed-optimized. STL (like C++) was designed for speed first (if at all possible then zero-cost abstractions) and thus does very little error checking on its own. Only kinda? A bunch of the containers then make other promises or leak details that prohibit meaningful optimizations. An extra branch in std::vector::pop_back() is such a pointless savings compared to, say, that std::map is basically mandatory red-black tree or that std::unordered_map must store elements in a linked list to preserver iterators across removals. Like almost none of the containers in the STL are "fast" at this point. std::vector is probably about the best, but even it is missing small-size optimizations (and that's ignoring the hair-brained bool specialization that then breaks everything)

tialaramex 4y ago
I had once assumed std::unordered_map was from the original Standard Template Library (which pre-dates C++ standardization), but turns out (I was told in a r/cpp thread) it's more modern. In 1998 std::unordered_map would have been an excusable design mistake, domain experts knew in 1998 that's a sub-optimal design for this dict / hashmap structure - but you could suppose perhaps they were not on the committee. In 2011 it's not an excusable mistake, better structures are widely known in academic and in industry - it was an unforced error. The more closely I look at it, the more I'm convinced that unsafety wasn't an inadvertent and undesirable consequence of a "must go fast" mindset in standard C++, unsafety was the whole point. It makes me think about that speech by Susan Sarandon's Rick & Morty character, Dr Wong. Dr Wong: "I have no doubt that you would be bored senseless by therapy, the same way I'm bored when I brush my teeth and wipe my ass, because the thing about repairing, maintaining, and cleaning is; it's not an adventure. There's no way to do it so wrong you might die." Software Engineering is an engineering discipline, it is not supposed to be an adventure. Programming C++ is an adventure, you can do it so wrong you might die. We should stop paying people to go on an adventure, let them do that exclusively on their free time if they want.
- gpderetta 4y ago
  hash_map was indeed part of the original STL, but was not standardized in C++98. It was still widely available, in slightly incompatible forms, as an extension. In C++11 it was standardized with only minor changes (and renamed). The address-preserving property, which precludes an optimal implementation, was considered important to be a near drop-in replacement of std::map.