-
The license was explicitly chosen to enable code sharing with LLVM's libc++ (https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-s...).
The MSVC STL's quality is good enough for thousands of pieces of Windows software (including Windows itself & Microsoft's software such as Office) to depend and rely on. It delivers excellent performance for a broad range of use cases. It is actively developed in the open, delivering cutting-edge (C++23 & C++26) features, accepting Pull Requests and wonderfully documented on GitHub. It can be consumed using MSVC and LLVM clang-cl (which the MSVC STL maintainers test with CI infrastructure). The maintainers are actively working on "hardening" features to enable more secure C++ (https://github.com/microsoft/STL/wiki/STL-Hardening).
Unless you specify what "best" or "a library's quality" means to you, MSVC STL is excellent and because of that, the default choice on & for Windows.
Google chooses to only support libc++ for Chrome/Chromium (https://chromium.googlesource.com/chromium/src/+/main/docs/t...). libc++ is not a Google-owned project.
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
Probably not as the way things are defined in the STL is often not in line with what C++ programmers want for their code base.
STL adheres to zero-cost-abstraction, which often puts safety in the backseat. Many programmers, myself included, prefer safety by default with an escape route, when its really needed.
Add to that things like exceptions, locale-dependent behavior, functions with a dozen overloads, an overly complex memory allocator interface (`std::vector` vs. `std::pmr::vector`), etc.
Personally, I'd prefer a common alternative to STL that focuses on these points. ETL [1] and abseil [2] come to mind, but it's not exactly what I envision.
1: https://github.com/ETLCPP/etl
-
-
SaferCPlusPlus
A collection of safe data types that are compatible with, and can substitute for, common unsafe native c++ types
> Many programmers, myself included, prefer safety by default with an escape route, when its really needed.
I'll just mention the SaferCPlusPlus library, which includes safe implementations of commonly used C++ elements: https://github.com/duneroadrunner/SaferCPlusPlus
-
EA Standard Template Library
EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.
-
The license was explicitly chosen to enable code sharing with LLVM's libc++ (https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-s...).
The MSVC STL's quality is good enough for thousands of pieces of Windows software (including Windows itself & Microsoft's software such as Office) to depend and rely on. It delivers excellent performance for a broad range of use cases. It is actively developed in the open, delivering cutting-edge (C++23 & C++26) features, accepting Pull Requests and wonderfully documented on GitHub. It can be consumed using MSVC and LLVM clang-cl (which the MSVC STL maintainers test with CI infrastructure). The maintainers are actively working on "hardening" features to enable more secure C++ (https://github.com/microsoft/STL/wiki/STL-Hardening).
Unless you specify what "best" or "a library's quality" means to you, MSVC STL is excellent and because of that, the default choice on & for Windows.
Google chooses to only support libc++ for Chrome/Chromium (https://chromium.googlesource.com/chromium/src/+/main/docs/t...). libc++ is not a Google-owned project.
