MSVC's implementation of the C++ Standard Library.
This is the official repository for Microsoft's implementation of the C++ Standard Library (also known as the STL), which ships as part of the MSVC toolset and the Visual Studio IDE.
If you're a programmer who just wants to use the STL, you don't need this repo. Simply install the Visual Studio IDE and select the "Desktop development with C++" workload.
If you want to participate in the STL's development, welcome! You can report issues, comment on pull requests, and learn about what we're working on. You can also submit pull requests to fix bugs or add features: see [CONTRIBUTING.md][] for more information.
Finally, you can take our code and use it in other apps and libraries (according to the terms of our license, like everything else).
We're in the process of moving all of our work on the STL to GitHub. Current status:
Code: Done. Our source code is available under the Apache License v2.0 with LLVM Exception. (See [LICENSE.txt][] and [NOTICE.txt][] for more information.)
Build System: In progress. We're working on a CMake build system, which is currently capable of building one
flavor of the STL (native desktop). We need to extend this to build all of the flavors required for the MSVC toolset
(e.g. /clr, /clr:pure, OneCore, Spectre). Until that's done, we're keeping our legacy build system around in the
stl/msbuild subdirectory. (We're keeping those files in this repo, even though they're unusable outside of Microsoft,
because they need to be updated whenever source files are added/renamed/deleted. We'll delete the legacy machinery as
soon as possible.)
Tests: In progress. We rely on three test suites: std, tr1, and [libcxx][]. We've partially ported std and tr1, and fully ported libcxx to run under [lit][] using the various configurations/compilers we test internally.
Continuous Integration: In progress. We've set up Azure Pipelines to validate changes to the repository. Currently, it builds the STL for x64, x86, ARM64, and ARM64EC. Also, it strictly verifies that all of our files have been formatted with [clang-format][] and follow our other whitespace conventions.
Contribution Guidelines: Coming soon. Working on the STL's code involves following many rules. We have codebase conventions, Standard requirements, Microsoft-specific requirements, binary compatibility (ABI) requirements, and more. We're eager to begin accepting features and fixes from the community, but in addition to setting up a CI system, we need to write down all of the rules that are currently stored in our brains. (The ABI rules may be useful to other C++ libraries.)
Issues: In progress. We're going to use GitHub issues to track all of the things that we need to work on. This includes C++20 features, [LWG issues][], conformance bugs, performance improvements, and other todos. There are approximately 200 active bugs in the STL's Microsoft-internal database; we need to manually replicate all of them to GitHub issues. Currently, the [cxx20 tag][] and [LWG tag][] are done; every remaining work item is tracked by a GitHub issue. The [bug tag][] and [enhancement tag][] are being populated.
Plans: In progress. We're writing up our [Roadmap][].
We're implementing the latest C++ Working Draft, currently [N5054][], which will eventually become the next C++
International Standard. The terms Working Draft (WD) and Working Paper (WP) are interchangeable; we often
informally refer to these drafts as "the Standard" while being aware of the difference. (There are other relevant
Standards; for example, supporting /std:c++14 and /std:c++17 involves understanding how the C++14 and C++17
Standards differ from the Working Paper, and we often need to refer to the C Standard Library and ECMAScript regular
expression specifications.)
Our primary goals are conformance, performance, usability, and compatibility.
Conformance: The Working Paper is a moving target; as features and LWG issue resolutions are added, we need to implement them. That can involve a lot of work because the STL is required to behave in very specific ways and to handle users doing very unusual things.
Performance: The STL needs to be extremely fast at runtime; speed is one of C++'s core strengths and most C++ programs use the STL extensively. As a result, we spend more time on optimization than most general-purpose libraries. (However, we're wary of changes that improve some scenarios at the expense of others, or changes that make code significantly more complicated and fragile. That is, there's a "complexity budget" that must be spent carefully.)
Usability: This includes parts of the programming experience like compiler throughput, diagnostic messages, and
debugging checks. For example, we've extensively marked the STL with [[nodiscard]] attributes because this helps
programmers avoid bugs.
Compatibility: This includes binary compatibility and source compatibility. We're keeping VS 2026 binary-compatible
with VS 2015-2022, which restricts what we can change in VS 2026 updates. (We've found that significant changes
are possible even though other changes are impossible, which we'll be documenting in our Contribution Guidelines soon.)
While there are a few exceptions to this rule (e.g. if a feature is added to the Working Paper, we implement it, and
then the feature is significantly changed before the International Standard is finalized, we reserve the right to break
binary compatibility because /std:c++latest offers an experimental preview of such features), binary compatibility
generally overrides all other considerations, even conformance. Source compatibility refers to being able to
successfully recompile user code without changes. We consider source compatibility to be important, but not
all-important; breaking source compatibility can be an acceptable cost if done for the right reasons in the right way
(e.g. in a controlled manner with escape hatches).
There are things that we aren't interested in doing with this project, for various reasons (most importantly, we need to focus development effort on our goals). Some examples:
Non-goal: Porting to other platforms.
Non-goal: Adding non-Standard extensions.
Non-goal: Implementing Technical Specifications. (We're prioritizing features in the Working Paper. Occasionally, we might implement some or all of a TS, often when we're working on the specification itself.)
If you're proposing a feature to WG21 (the C++ Standardization Committee), you're welcome (and encouraged!) to use our code as a base for a proof-of-concept implementation. These non-goals simply mean that we're unable to consider pull requests for a proposed feature until it has been voted into a Working Paper. After that happens, we'll be delighted to review a production-ready pull request.
You can report STL bugs here, where they'll be directly reviewed by maintainers. You can also report STL bugs through [Developer Community][], or the VS IDE (Help > Send Feedback > Report a Problem...).
Please help us efficiently process bug reports by following these rules:
Only STL bugs should be reported here. If it's a bug in the compiler, CRT, or IDE, please report it through Developer Community or Report A Problem. If it's a bug in the Windows SDK, please report it through the [Feedback Hub][hub] app. If you aren't sure, try to reduce your test case and see if you can eliminate the STL's involvement while still reproducing the bug.
You should be reasonably confident that you're looking at an actual implementation bug, instead of undefined behavior or surprising-yet-Standard behavior. Comparing against other implementations can help (but remember that implementations can differ while conforming to the Standard); try [Compiler Explorer][]. If you still aren't sure, ask the nearest C++ expert.
You should prepare a self-contained command-line test case, ideally as small as possible. We need a source file, a command line, what happened (e.g. a compiler error, runtime misbehavior), and what you expected to happen. By "self-contained", we mean that your source file has to avoid including code that we don't have. Ideally, only CRT and STL headers should be included. If you have to include other MSVC libraries, or the Windows SDK, to trigger an STL bug, that's okay. But if you need parts of your own source code to trigger the STL bug, you need to extract that for us. (On Developer Community, we'll accept zipped IDE projects if you have no other way to reproduce a bug, but this is very time-consuming for us to reduce.)
A good title is helpful. We prefer "<header_name>: Short description of your issue". You don't usually need to
mention std:: or C++. For example, "<type_traits>: is_cute should be true for enum class FluffyKittens".
It's okay if you report an apparent STL bug that turns out to be a compiler bug or surprising-yet-Standard behavior. Just try to follow these rules, so we can spend more time fixing bugs and implementing features.
python.
Otherwise, you should be familiar with alternative methods.Note 1: The STL and the compiler ship together, and we frequently need recently implemented
compiler fixes and features, so the Latest build tools (i.e. latest production) are too old.
Because the Insiders IDE supports having the Latest and Preview build tools installed simultaneously,
you need to ensure that you're using the Preview build tools. If you build with the IDE, we've arranged for
this to happen automatically. If you build with the Command Prompt, you need to pass -vcvars_ver=preview
as explained below. For more info, read the [C++ Team Blog post][preview] that announced this release process.
Note 2: The x64/x86 build tools are usually sufficient.
You'll need the ARM64/ARM64EC build tools if you're working with architecture-sensitive code.
For example, <atomic> has conditionally compiled code for the _M_ARM64 and _M_ARM64EC predefined macros.
https://github.com/microsoft/STL.git as the repository location. Choose a local path. Click "Clone".git clone https://github.com/microsoft/STL.git --recurse-submodulespushd STLThe following instructions assume that you're s
`<regex>`: `regex_search()` throws `regex_error(error_complexity)` with an unwisely written pattern
P2821R5 `span::at()`
Write Visual Studio visualizations using C++
ARM64/ARM64EC runtime assertions in `P0811R3_midpoint_lerp`
`<algorithm>`: `ranges::min`, `ranges::max` and `ranges::minmax` evaluate each element twice
`<cmath>`: `constexpr` `fpclassify()` rejects signaling NaNs on x86
P3726R2 Adjustments To Union Lifetime Rules
`<xutility>`: std::find no longer compiles with structs with defaulted equality comparison with Clang-CL
Size-based representation for std::vector
P0792R14 `function_ref`: A Type-Erased Callable Reference