string & vector types: STL, 1998 type conversion operators: 1998. mutable keyword: 1998. collection library: STL, 1998. smart pointers: STL, auto_ptr<> in C++98
I'd argue that without STL & C++98, C++ would've languished even longer. And with STL, it still took another 5 years for the compilers to be good enough.
This is under-stated, IMO. It wasn't really until 2004 or even later that we had high-quality support for C++98 in GCC. LLVM wasn't available, yet. Heaven help you if you wanted to develop in C++ on OSX, since Apple's packaging of GCC was a total disaster. Step zero for developing C++ on OSX was "install GCC from FSF sources" for many years.
Even MSVC support was lagging. It wasn't until the Microsoft tools leadership got involved with C++11 that MSVC took standard support seriously. They were already prioritizing .NET in that timeframe.
Meanwhile, the big open-source desktop C++ libraries (Qt and WxWindows) still don't fully take advantage of the types and features in the standard library in 2021.
If you were developing Mac programs in C++ back then, you were probably using Metrowerks CodeWarrior.
Of course not. C++ and libraries don't go along nicely. STL is not really useful for cross boundary interop due the fact that C++ ABI is not stable.
Shipping libraries that leak STL types all over the place will only give you headache.
Namely:
- proper string and vector types (most compilers allow to enable bounds checking anyway)
- stronger rules for type conversions
- reference types for parameters
- better tooling for immutable data structures
- memory allocation primitives instead of getting sizeof wrong to malloc()
- collection library instead of reinventing the wheel in each project
- RAII
- smart pointers
- templates instead of error prone macros
- namespacing (usefull in large scale projects with prefix tricks)