[kllrnohj]

> 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]

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]

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>.

[gpderetta]

STL (if we use this name as a arguably incorrect alias for the c++ standard library) is intrinsically linked with the language. A lot of its implementation requires primitives that are not part of the language (although often exposed as intrinsics as an extension). An implementation can and often does treat the names under namespace std specially and assumes invariants and behavior.

[pjmlp]

The S in STL stands for Standard, something that neither boost nor Abseil are, or will ever be.

[kllrnohj]

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]

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.

[de_watcher]

You're a troll from 2003. I remember huge forum threads about STL.

Now it's the Standard Library like in any other language.