5 ms·

> You have that backwards. The STL containers are for when you have a hyper-specific niche use case. That assertion makes no sense at all. The stl contrainers

> You have that backwards. The STL containers are for when you have a hyper-specific niche use case. That assertion makes no sense at all. The stl contrainers work very well as basic generic containers that can safely be used for pretty much any conceivable use where performance isn't super critical. I'm talking about cases like, say, you need to map keys to values but you don't really care about performance or which specific data structure you're using. That's stl's domain: robust, bullet-proof implementations of basic data structures that are good enough for most (or practically all) cases with the exception of a few very niche applications. If you happen to be one of the rare cases where you feel you need to know if a container is built around a red-black tree or any other fancy arcane data structure, and if this so critical to you that you feel the need to benchmark the performance to assess whether you either need to use non-defaults or completely replace parts or the whole container with a third-party alternative... Then and only then the stl is not for you.

kllrnohj 7y ago
This makes no sense. The STL is the specialized containers with obscure performance characteristics & behaviors. Boost & abseil provide the generic, reasonable default ones. You're arguing it's better to use something that's across the board worse for nearly every user, and by a lot, just because... why? It's slightly more convenient?
- pjmlp 7y ago
  Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler, and does not require lots of paperwork for adoption at many shops.
  - kllrnohj 7y ago
    > Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler No it isn't and no it's not. There are even platforms where an STL isn't even provided out of the box, you have to pick one. And there's quite a few at that - libc++, libstdc++, stlport, etc... But clang, g++, etc... they don't care. To them it's just another library you're linking against, no different from any other dependency. They don't provide it, they don't care. It can even be quite a pain in the ass to use the "native" STL of a given compiler, like trying to use libc++ with Clang on most Linux distros.
    - pjmlp 7y ago
      Only ISO C++ compliant platforms matter. As having multiple implementations to choose from, that is the beauty of language standards. Abseil and boost do not fall under that umbrella, and I belong to the C++ subculture that never ever touched them, or plans to.
      - cmroanirgo 7y ago
        STL by it's very name is a library, and because it ships with a compiler, doesn't mean it's part of that compiler. It's just a library, like Boost. It might have some ISO standards behind it: great! But it's still a library and not intrinsic to the language itself (see my orig question). eg. to use an 'int' you just declare one and use it. To use strings, you need to include <string.h>.
        pjmlp 7y ago
        The S in STL stands for Standard, something that neither boost nor Abseil are, or will ever be.
        kllrnohj 7y ago
        Being in the standard doesn't mean they are good or should be used. java.util.Vector is standard as well but you'd be laughed out of a code review if you tried to use it anywhere. Similarly std::auto_ptr is in the standard, and is universally agreed to be trash to avoid like the plague. So much so it was (eventually) removed. The container section of the library has just sadly not had the same deprecation & removal of bad code put into it. The claim was "STL containers are the sane default" not that "STL containers are more available". I stand by that claim being wrong. You have so far not actually attempted to counter it on any technical grounds, just bad appeal to authority fallacies.
        pjmlp 7y ago
        Except that java.util.Vector is for backwards compatibility and everyone should use java.util.ArrayList instead. Likewise std::auto_ptr got replaced by std::unique_ptr. As you see the standard library keeps the knowledgable developers covered, no need to look elsewhere. You are indeed wrong.
- rumanator 7y ago
  > This makes no sense. The STL is the specialized containers It really isn't. The whole STL is, by design, a template library packed with generic data structures that are designed to have very robust defaults and still be customizable and extensible. When the defaults are good enough, which is the case in general, the STL will do. If you have a niche requirement (say, games) or feel adventurous, you adopt custom and/or specialized solutions. This has been the case since the STL's inception. They are the standard, default library. I can't understand how someone is able to miss this fact.

kllrnohj 7y ago

This makes no sense. The STL is the specialized containers with obscure performance characteristics & behaviors. Boost & abseil provide the generic, reasonable default ones. You're arguing it's better to use something that's across the board worse for nearly every user, and by a lot, just because... why? It's slightly more convenient?

pjmlp 7y ago
Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler, and does not require lots of paperwork for adoption at many shops.
- kllrnohj 7y ago
  > Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler No it isn't and no it's not. There are even platforms where an STL isn't even provided out of the box, you have to pick one. And there's quite a few at that - libc++, libstdc++, stlport, etc... But clang, g++, etc... they don't care. To them it's just another library you're linking against, no different from any other dependency. They don't provide it, they don't care. It can even be quite a pain in the ass to use the "native" STL of a given compiler, like trying to use libc++ with Clang on most Linux distros.
  - pjmlp 7y ago
    Only ISO C++ compliant platforms matter. As having multiple implementations to choose from, that is the beauty of language standards. Abseil and boost do not fall under that umbrella, and I belong to the C++ subculture that never ever touched them, or plans to.
    - cmroanirgo 7y ago
      STL by it's very name is a library, and because it ships with a compiler, doesn't mean it's part of that compiler. It's just a library, like Boost. It might have some ISO standards behind it: great! But it's still a library and not intrinsic to the language itself (see my orig question). eg. to use an 'int' you just declare one and use it. To use strings, you need to include <string.h>.
      - pjmlp 7y ago
        The S in STL stands for Standard, something that neither boost nor Abseil are, or will ever be.
        kllrnohj 7y ago
        Being in the standard doesn't mean they are good or should be used. java.util.Vector is standard as well but you'd be laughed out of a code review if you tried to use it anywhere. Similarly std::auto_ptr is in the standard, and is universally agreed to be trash to avoid like the plague. So much so it was (eventually) removed. The container section of the library has just sadly not had the same deprecation & removal of bad code put into it. The claim was "STL containers are the sane default" not that "STL containers are more available". I stand by that claim being wrong. You have so far not actually attempted to counter it on any technical grounds, just bad appeal to authority fallacies.
        pjmlp 7y ago
        Except that java.util.Vector is for backwards compatibility and everyone should use java.util.ArrayList instead. Likewise std::auto_ptr got replaced by std::unique_ptr. As you see the standard library keeps the knowledgable developers covered, no need to look elsewhere. You are indeed wrong.
rumanator 7y ago
> This makes no sense. The STL is the specialized containers It really isn't. The whole STL is, by design, a template library packed with generic data structures that are designed to have very robust defaults and still be customizable and extensible. When the defaults are good enough, which is the case in general, the STL will do. If you have a niche requirement (say, games) or feel adventurous, you adopt custom and/or specialized solutions. This has been the case since the STL's inception. They are the standard, default library. I can't understand how someone is able to miss this fact.