MSVC's implementation of the C++ Standard Library.

Overview

Microsoft's 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.

Build Status

What This Repo Is Useful For

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

Finally, you can take our code and use it in other apps and libraries (according to the terms of our license, like everything else).

GitHub Migration Status

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 (native desktop for x86, x64, ARM, and ARM64). 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.

Goals

We're implementing the latest C++ Working Draft, currently N4901, 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 2022 binary-compatible with VS 2015/2017/2019, which restricts what we can change in VS 2022 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).

Non-Goals

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.

Reporting Issues

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 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 Godbolt's Compiler Explorer and Wandbox. 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 " : Short description of your issue". You don't usually need to mention std:: or C++. For example, " : 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.

How To Build With The Visual Studio IDE

  1. Install Visual Studio 2022 17.1 Preview 1 or later.
    • We recommend selecting "C++ CMake tools for Windows" in the VS Installer. This will ensure that you're using supported versions of CMake and Ninja.
    • Otherwise, install CMake 3.21 or later, and Ninja 1.10.2 or later.
    • We recommend selecting "Python 3 64-bit" in the VS Installer.
    • Otherwise, make sure Python 3.9 or later is available to CMake.
  2. Open Visual Studio, and choose the "Clone or check out code" option. Enter the URL of this repository, https://github.com/microsoft/STL.
  3. Open a terminal in the IDE with Ctrl + ` (by default) or press on "View" in the top bar, and then "Terminal".
  4. In the terminal, invoke git submodule update --init --progress llvm-project boost-math
  5. Choose the architecture you wish to build in the IDE, and build as you would any other project. All necessary CMake settings are set by CMakeSettings.json.

How To Build With A Native Tools Command Prompt

  1. Install Visual Studio 2022 17.1 Preview 1 or later.
    • We recommend selecting "C++ CMake tools for Windows" in the VS Installer. This will ensure that you're using supported versions of CMake and Ninja.
    • Otherwise, install CMake 3.21 or later, and Ninja 1.10.2 or later.
    • We recommend selecting "Python 3 64-bit" in the VS Installer.
    • Otherwise, make sure Python 3.9 or later is available to CMake.
  2. Open a command prompt.
  3. Change directories to a location where you'd like a clone of this STL repository.
  4. git clone https://github.com/microsoft/STL --recurse-submodules

To build the x86 target:

  1. Open an "x86 Native Tools Command Prompt for VS 2022 Preview".
  2. Change directories to the previously cloned STL directory.
  3. cmake -G Ninja -S . -B out\build\x86
  4. ninja -C out\build\x86

To build the x64 target (recommended):

  1. Open an "x64 Native Tools Command Prompt for VS 2022 Preview".
  2. Change directories to the previously cloned STL directory.
  3. cmake -G Ninja -S . -B out\build\x64
  4. ninja -C out\build\x64

How To Consume

Consumption of the built library is largely based on the build system you're using. There are at least 2 directories you need to hook up. Assuming you built the x64 target with the Visual Studio IDE, with the STL repository cloned to C:\Dev\STL, build outputs will end up at C:\Dev\STL\out\build\x64\out. Ensure that the inc directory is searched for headers, and that lib\{architecture} is searched for link libraries, before any defaults supplied by MSVC. The names of the import and static libraries are the same as those that ship with MSVC. As a result, the compiler /MD, /MDd, /MT, or /MTd switches will work without modification of your build scripts or command-line muscle memory.

Should you choose to use the DLL flavors, the DLLs to deploy are built to bin\{architecture}. Note that the DLLs generated by the CMake build system here have a suffix, defaulting to _oss, which distinguishes them from the binaries that ship with MSVC. That avoids any conflict with the DLLs installed by the redistributables into System32, and ensures that other components wanting to be a "guest in your process", like print drivers and shell extensions, see the export surface of the STL they were built with. Otherwise, the "msvcp140.dll" you deployed in the same directory as your .exe would "win" over the versions in System32.

Complete Example Using x64 DLL Flavor

The compiler looks for include directories according to the INCLUDE environment variable, and the linker looks for import library directories according to the LIB environment variable, and the Windows loader will (eventually) look for DLL dependencies according to directories in the PATH environment variable. From an "x64 Native Tools Command Prompt for VS 2022 Preview":

cl /nologo /EHsc /W4 /WX /MDd /std:c++latest .\example.cpp example.cpp C:\Users\username\Desktop>.\example.exe Hello STL OSS world! C:\Users\username\Desktop>dumpbin /IMPORTS .\example.exe | findstr msvcp msvcp140d_oss.dll">
C:\Users\username\Desktop>set INCLUDE=C:\Dev\STL\out\build\x64\out\inc;%INCLUDE%

C:\Users\username\Desktop>set LIB=C:\Dev\STL\out\build\x64\out\lib\amd64;%LIB%

C:\Users\username\Desktop>set PATH=C:\Dev\STL\out\build\x64\out\bin\amd64;%PATH%

C:\Users\username\Desktop>type example.cpp
#include 
   
    

int main() {
    std::cout << "Hello STL OSS world!\n";
}

C:\Users\username\Desktop>cl /nologo /EHsc /W4 /WX /MDd /std:c++latest .\example.cpp
example.cpp

C:\Users\username\Desktop>.\example.exe
Hello STL OSS world!

C:\Users\username\Desktop>dumpbin /IMPORTS .\example.exe | findstr msvcp
    msvcp140d_oss.dll

   

How To Run The Tests With A Native Tools Command Prompt

  1. Follow either How To Build With A Native Tools Command Prompt or How To Build With The Visual Studio IDE.
  2. Acquire Python 3.9 or newer and have it on the PATH (or run it directly using its absolute or relative path).
  3. Have LLVM's bin directory on the PATH (so clang-cl.exe is available).
    • We recommend selecting "C++ Clang tools for Windows" in the VS Installer. This will automatically add LLVM to the PATH of the x86 and x64 Native Tools Command Prompts, and will ensure that you're using a supported version.
    • Otherwise, use LLVM's installer and choose to add LLVM to your PATH during installation.
  4. Follow the instructions below.

Running All The Tests

After configuring and building the project, running ctest from the build output directory will run all the tests. CTest will only display the standard error output of tests that failed. In order to get more details from CTest's lit invocations, run the tests with ctest -V.

Running A Subset Of The Tests

${PROJECT_BINARY_DIR}\tests\utils\stl-lit\stl-lit.py can be invoked on a subdirectory of a testsuite and will execute all the tests under that subdirectory. This can mean executing the entirety of a single testsuite, running all tests under a category in libcxx, or running a single test in std and tr1.

Examples

These examples assume that your current directory is C:\Dev\STL\out\build\x64.

  • This command will run all of the testsuites with verbose output.
    • ctest -V
  • This command will also run all of the testsuites.
    • python tests\utils\stl-lit\stl-lit.py ..\..\..\llvm-project\libcxx\test ..\..\..\tests\std ..\..\..\tests\tr1
  • This command will run all of the std testsuite.
    • python tests\utils\stl-lit\stl-lit.py ..\..\..\tests\std
  • If you want to run a subset of a testsuite, you need to point it to the right place in the sources. The following will run the single test found under VSO_0000000_any_calling_conventions.
    • python tests\utils\stl-lit\stl-lit.py ..\..\..\tests\std\tests\VSO_0000000_any_calling_conventions
  • You can invoke stl-lit with any arbitrary subdirectory of a testsuite. In libcxx this allows you to have finer control over what category of tests you would like to run. The following will run all the libcxx map tests.
    • python tests\utils\stl-lit\stl-lit.py ..\..\..\llvm-project\libcxx\test\std\containers\associative\map

Interpreting The Results Of Tests

CTest

When running the tests via CTest, all of the testsuites are considered to be a single test. If any single test in a testsuite fails, CTest will simply report that the stl test failed.

Example:

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 2441.55 sec

The following tests FAILED:
      1 - stl (Failed)

The primary utility of CTest in this case is to conveniently invoke stl-lit.py with the correct set of arguments.

CTest will output everything that was sent to stderr for each of the failed testsuites, which can be used to identify which individual test within the testsuite failed. It can sometimes be helpful to run CTest with the -V option in order to see the stdout of the tests.

stl-lit

When running the tests directly via the generated stl-lit.py script the result of each test will be printed. The format of each result is {Result Code}: {Testsuite Name} :: {Test Name}:{Configuration Number}.

Example:

-- Testing: 28 tests, 12 workers --
PASS: tr1 :: tests/cwchar1:01 (1 of 28)
PASS: tr1 :: tests/cwchar1:11 (2 of 28)
PASS: tr1 :: tests/cwchar1:02 (3 of 28)
PASS: tr1 :: tests/cwchar1:03 (4 of 28)
PASS: tr1 :: tests/cwchar1:00 (5 of 28)
PASS: tr1 :: tests/cwchar1:04 (6 of 28)
PASS: tr1 :: tests/cwchar1:05 (7 of 28)
PASS: tr1 :: tests/cwchar1:09 (8 of 28)
PASS: tr1 :: tests/cwchar1:06 (9 of 28)
UNSUPPORTED: tr1 :: tests/cwchar1:20 (10 of 28)
UNSUPPORTED: tr1 :: tests/cwchar1:21 (11 of 28)
UNSUPPORTED: tr1 :: tests/cwchar1:22 (12 of 28)
UNSUPPORTED: tr1 :: tests/cwchar1:23 (13 of 28)
UNSUPPORTED: tr1 :: tests/cwchar1:24 (14 of 28)
PASS: tr1 :: tests/cwchar1:07 (15 of 28)
PASS: tr1 :: tests/cwchar1:08 (16 of 28)
PASS: tr1 :: tests/cwchar1:10 (17 of 28)
PASS: tr1 :: tests/cwchar1:16 (18 of 28)
PASS: tr1 :: tests/cwchar1:17 (19 of 28)
PASS: tr1 :: tests/cwchar1:14 (20 of 28)
PASS: tr1 :: tests/cwchar1:12 (21 of 28)
PASS: tr1 :: tests/cwchar1:13 (22 of 28)
PASS: tr1 :: tests/cwchar1:19 (23 of 28)
PASS: tr1 :: tests/cwchar1:18 (24 of 28)
PASS: tr1 :: tests/cwchar1:15 (25 of 28)
PASS: tr1 :: tests/cwchar1:25 (26 of 28)
PASS: tr1 :: tests/cwchar1:26 (27 of 28)
PASS: tr1 :: tests/cwchar1:27 (28 of 28)

Testing Time: 3.96s
  Expected Passes    : 23
  Unsupported Tests  : 5

In the above example we see that 23 tests succeeded and 5 were unsupported.

Result Code Values

Our tests use the standard lit result codes, and an undocumented result code: SKIPPED. For our tests, only the PASS, XFAIL, XPASS, FAIL, UNSUPPORTED, and SKIPPED result codes are relevant.

The PASS and FAIL result codes are self-explanatory. We want our tests to PASS and not FAIL.

The XPASS and XFAIL result codes are less obvious. XPASS is actually a failure result and indicates that we expected a test to fail but it passed. XFAIL is a successful result and indicates that we expected the test to fail and it did. Typically an XPASS result means that the expected_results.txt file for the testsuite needs to be modified. If the XPASS result is a test legitimately passing, the usual course of action would be to remove a FAIL entry from the expected_results.txt. However, some tests from libcxx mark themselves as XFAIL (meaning they expect to fail) for features they have added tests for but have yet to implement in libcxx. If the STL implements those features first the tests will begin passing unexpectedly for us and return XPASS results. In order to resolve this it is necessary to add a PASS entry to the expected_results.txt of the testsuite in question.

The UNSUPPORTED result code means that the requirements for a test are not met and so it will not be run. Currently all tests which use the /clr or /clr:pure options are unsupported. Also, the /BE option is unsupported for x86.

The SKIPPED result code indicates that a given test was explicitly skipped by adding a SKIPPED entry to the expected_results.txt. A test may be skipped for a number of reasons, which include, but are not limited to:

  • being an incorrect test
  • taking a very long time to run
  • failing or passing for the incorrect reason

Debugging Individual Tests

While stl-lit is super awesome in finding out that something is wrong or not even compiling, it is not really helpful in debugging what is going wrong. However, debugging individual tests is rather simple given some additional steps. Let's assume we want to debug a new feature with tests located in tests\std\tests\GH_XXXX_meow.

As always, build the STL from your branch and run the tests:

C:\STL\out\build\x64> ninja
C:\STL\out\build\x64> python tests\utils\stl-lit\stl-lit.py -v C:\STL\tests\std\tests\GH_XXXX_meow

Let's assume one of the tests fails an assert and we want to debug that configuration. stl-lit will conveniently print the build command, which is far too long to provide here in full. The important part is to add the following options to provide debug symbols: /Zi /Fdbark.pdb.

You can replace bark with any descriptive name you like. Add these before the "-link" option in the command line and recompile. Example:

C:\STL\out\build\x64>cl "C:\STL\tests\std\tests\GH_XXXX_meow\test.cpp" [... more arguments ...]
"-FeC:\STL\out\build\x64\tests\std\tests\GH_XXXX_meow\Output\02\GH_XXXX_meow.exe" /Zi /Fdbark.pdb "-link"
[... more arguments ...]

You can now start debugging the test via:

devenv "C:\STL\out\build\x64\tests\std\tests\GH_XXXX_meow\Output\02\GH_XXXX_meow.exe"
       "C:\STL\tests\std\tests\GH_XXXX_meow\test.cpp"

However, this might not work right away, as Visual Studio may complain about a missing msvcp140_oss.dll. The reason is that the STL builds those and other DLLs itself and we should under no circumstances overwrite the installed ones. If you are testing one of the configurations with dynamic linkage (/MD or /MDd) the easiest solution is to add the build folder to your path:

set PATH=C:\STL\out\build\x64\out\bin\amd64;%PATH%

Editing And Testing The Debugger Visualizer

Modify The Visualizer

To modify how components are visualized in the debugger, edit the file stl\debugger\STL.natvis. For more information on how to modify this file, check the natvis documentation.

Test Your Changes

You can add the natvis file to any Visual Studio C++ project if you right click your project > Add > Existing Item and select the STL.natvis file. After doing this you should be able to see your changes in a Visual Studio debugging session.

Block Diagram

The STL is built atop other compiler support libraries that ship with Windows and Visual Studio, like the UCRT, VCRuntime, and VCStartup. The following diagram describes the dependencies between those components and their ship vehicles.

MSVC Libraries Block Diagram

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

Code Of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

License

Copyright (c) Microsoft Corporation.

SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception

Issues
  • Implementation of std::atomic::wait

    Implementation of std::atomic::wait

    Description

    Implementation of std::atomic::wait , part of #52

    Partly based on https://github.com/ogiroux/atomic_wait (no code copying, but being familiar with that implementation) (initially; currently it substantially diverges from that idea)

    Design decisions:

    • Run-time selection between WaitOnAddress and fallback. Still when STL targets Windows 8+ (ARM), the decision to use WaitOnAddress is made at compile time
    • Fall back to Condition Variable + SRW Lock, since not targeting older systems, like Windows XP and older
    • Do not use a flag whether "Wake" call is needed. 'WakeByAddressSingle' / 'WakeByAddressAll' do this check by itself
    • Do not spin when target address is directly passed to WaitOnAddress, since WaitOnAddress spins by itself (and SleepConditionVariableSRW is expecteed to spin too, though did not check that).
    • Checking is done in header. Other operations are in atomic_wait.cpp. When DLL run-time library is used, it is in a satellite DLL

    Known issues:

    • Does not yet cover atomic_shared_ptr. Another change maybe.
    • The 16 bytes lock-free case is not tested yet. It will be tested when atomic_ref is merged, as it is available only for atomic_ref

    Checklist

    Be sure you've read README.md and understand the scope of this repo.

    If you're unsure about a box, leave it unchecked. A maintainer will help you.

    • [x] Identifiers in product code changes are properly _Ugly as per https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
    • [x] The STL builds successfully and all tests have passed (must be manually verified by an STL maintainer before automated testing is enabled on GitHub, leave this unchecked for initial submission).
    • [x] These changes introduce no known ABI breaks (adding members, renaming members, adding virtual functions, changing whether a type is an aggregate or trivially copyable, etc.).
    • [x] These changes were written from scratch using only this repository, the C++ Working Draft (including any cited standards), other WG21 papers (excluding reference implementations outside of proposed standard wording), and LWG issues as reference material. If they were derived from a project that's already listed in NOTICE.txt, that's fine, but please mention it. If they were derived from any other project (including Boost and libc++, which are not yet listed in NOTICE.txt), you must mention it here, so we can determine whether the license is compatible and what else needs to be done.
    cxx20 
    opened by AlexGuteniev 136
  • <span> Implement span

    Implement span

    Description

    This is a work in progress of the implementation of std::span (See #4 )

    Checklist:

    • [x] I understand README.md.
    • [x] If this is a feature addition, that feature has been voted into the C++ Working Draft.
    • [x] Identifiers in any product code changes are properly _Ugly as per https://eel.is/c++draft/lex.name#3.1 .
    • [x] Identifiers in test code changes are not _Ugly.
    • [x] Test code includes the correct headers as per the Standard, not just what happens to compile.
    • [x] The STL builds and test harnesses have passed (must be manually verified by an STL maintainer before CI is online, leave this unchecked for initial submission).
    • [x] This change introduces no known ABI breaks (adding members, renaming members, adding virtual functions, changing whether a type is an aggregate or trivially copyable, etc.). If unsure, leave this box unchecked and ask a maintainer for help.

    However, there are some troubles. I went with _Compressed_pair to implement static extent, however it seems that it is not constexpr-friendly. The tests that I have shamelessly copied from libcxx can be found here.

    At this point I am unsure, which option is better:

    1. Make _Compressed_pair fully constexpr-friendly
    2. Roll a new span specific solutio similar to what the gsl did
    3. Add a general facility next to _Compressed_pair that is constexpr-friendly

    Also I followed the approach of string_view and added an indirection however I an unsure whether that is really necessary

    opened by miscco 66
  • <chrono> Partially implement P0355R7

    Partially implement P0355R7

    Description

    Partially implemented #12; [time.point.arithmetic] and [time.cal] (excluding I/O)

    I've used a couple of Howard's algorithms, which I hope is okay as it's public domain

    Consider these donated to the public domain

    ~~I originally used Howard's algorithm for year_­month_­day::operator sys_days() but I just saw LWG3206 in the issue thread and switched to it however it broke my test project's uses of constexpr due to the depth limit.~~ I did eventually realise this was just a result of poor reading comprehension on my end.

    Speaking of constexpr I had to disable the warning for negative integral => unsigned as uses of it in constexpr contexts fail to compile. No idea if that was the correct thing to do.

    There is more than likely a better way of doing year_month_weekday::operator sys_days() const than how I implemented it. edit: I believe I've improved this.

    During testing I found that this code triggers an ICE

    constexpr auto test = 2019y / November / 24;
    constexpr auto ymwdl =  2019y / November  / weekday_last{ Sunday };
    constexpr sys_days _Last{ 2019y / November / last };
    

    I think everything should be noexcept /* strengthened */? If so are they applied to declarations, definitions, or both?

    Checklist

    Be sure you've read README.md and understand the scope of this repo.

    If you're unsure about a box, leave it unchecked. A maintainer will help you.

    • [x] Identifiers in product code changes are properly _Ugly as per https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
    • [ ] The STL builds successfully and all tests have passed (must be manually verified by an STL maintainer before automated testing is enabled on GitHub, leave this unchecked for initial submission).
    • [x] These changes introduce no known ABI breaks (adding members, renaming members, adding virtual functions, changing whether a type is an aggregate or trivially copyable, etc.).
    • [ ] These changes were written from scratch using only this repository, the C++ Working Draft (including any cited standards), other WG21 papers (excluding reference implementations outside of proposed standard wording), and LWG issues as reference material. If they were derived from a project that's already listed in NOTICE.txt, that's fine, but please mention it. If they were derived from any other project (including Boost and libc++, which are not yet listed in NOTICE.txt), you must mention it here, so we can determine whether the license is compatible and what else needs to be done.
    cxx20 
    opened by SuperWig 60
  • Port DevCom bugs to GitHub

    Port DevCom bugs to GitHub

    As part of our work to migrate all STL development to GitHub, we're porting our Microsoft-internal bug database ("VSO"; originally Visual Studio Online, renamed Azure DevOps and Azure Boards) to GitHub issues. Some bugs were directly filed in VSO (by STL maintainers and other people within MS, sometimes on behalf of customers), while some were replicated from Developer Community ("DevCom").

    As part of this porting process, we aren't resolving any bugs. The intended goal is for GitHub to be the source of truth for all bug reports (in addition to performance/enhancement/etc. suggestions); it's also our preferred place for new issues to be filed. (Issues filed on GitHub aren't replicated anywhere else, so it's the most convenient for us.) However, users who filed DevCom bugs in the past (or continue to file them in the future) will have their bugs remain active, and will receive feedback from STL maintainers there (in addition to their bugs being ported to GitHub issues where they can be linked to pull requests etc.). Additionally, VSO bugs (whether filed directly or replicated from DevCom) will remain active because our bosses and boss-like entities prefer that.

    "Porting" a bug to GitHub involves capturing the true essence of the bug report, without distorting or over-simplifying it. (Much like compiler bugs, STL bugs can be very sensitive to the exact code, compiler options, etc. used.) However, we also want our GitHub issues to be readable and comprehensible, so that both maintainers and contributors can understand what's wrong and easily investigate a fix. So, when possible, it's nice to clean up the title and test case, so that they're as clear and minimal as possible. (It is often a good idea to have an "original repro" and "reduced repro", to avoid the dangers of over-simplifying away something important - and I speak as someone who has over-simplified a dozen compiler bug reports in the past.) It's better to err on the side of less cleanup than more - fixing only grammatical issues is fine.

    Example bugs ported from DevCom: GH-371 (from DevCom-758960) and GH-503 (from DevCom-371962)

    While only the STL maintainers will be able to port the MS-internal bugs that were directly filed in VSO, the DevCom database is publicly viewable, so we could use some help with those bugs. :smile_cat:

    Here's a list of the DevCom bugs, along with their VSO IDs and Titles. (Sometimes, multiple DevCom bugs were linked to a single VSO bug, when we had a strong belief that they're all duplicates.) I generated this by hand, so if anything looks wrong (e.g. mismatched VSO/DevCom bugs), please let me know. Note that everyone in this repo has the ability to use our Custom Autolinks in GitHub issues/comments; you can just say DevCom-NNN instead of copying a whole URL.

    In general, we have already tried to resolve clearly-invalid bugs, and obvious duplicates, but there are several categories of possible duplicates that we haven't resolved because there may be multiple underlying issues.

    Finally, in addition to the title and repro, ported bugs should mention the DevCom and VSO IDs, so we can easily navigate to the linked bugs:

    Also tracked by DevCom-publicnumber and VSO-internalnumber / AB#internalnumber.

    AB followed by # (not - like other autolinks) will activate automation: your issue will be automatically edited by @msalehmsft to add a hyperlink (it won't appear in a Preview), and the internal bug will gain a special link. This must be mentioned in the original issue to create the internal link; using this syntax in issue comments below will be hyperlinked from GitHub, but not to GitHub.

    Please don't use AB#nnn syntax here, in this thread as it will link "Port DevCom bugs to GitHub" to whatever's mentioned. DevCom-nnn and VSO-nnn are safe to mention anywhere.

    :beetle: Remaining: VSO ID | DevCom ID(s) | Original VSO Title

    • All done!

    :hourglass_flowing_sand: In Progress

    • None.

    :warning: Blocked

    • Let us know if anything simply can't be ported due to test cases in non-public attachments, descriptions that don't make sense, etc. We'll handle these bugs separately.
    • Non-public attachments:
      • [ ] VSO-238123 | DevCom-189336 | <iomanip>: std::get_time cause Debug Assertion Failed when the second parameter have extra delimiter
      • [ ] VSO-275595 | DevCom-246257 | <regex>: Instantiating std::regex("meow") changes output of strftime in a different thread
      • [ ] VSO-406125 | DevCom-246250 | <iomanip>: std::get_time does not report fail on an invalid date
    • Non-public screenshots:
      • [ ] VSO-659137 | DevCom-305560 | <xlocale> et al. locale allocates memory while holding the locale lock
    • Needs extra attention, see linked comments below:
      • [ ] https://github.com/microsoft/STL/issues/939#issuecomment-653840746 | VSO-399948 | DevCom-249123 DevCom-86665 DevCom-267556 | <regex> std::regex_search causes infinite recursion on a sample that works with Visual Studio 2013 and gcc

    :x: Resolved As Invalid

    • [x] VSO-471859 | DevCom-87221 DevCom-246246 | <scoped_allocator>: std::scoped_allocator_adaptor copy constructor does not copy construct inner allocators
    • [x] GH-1122 | VSO-441122 | DevCom-59694 | <iostream> : When a double-width characters in cout, blank output without permission.

    :hammer_and_wrench: Compiler Bug, Reduced To Library-Free Test Case And Sent To Compiler Team

    • [x] VSO-1168175 | DevCom-1139739 | std::thread ends up calling lambda from other file with new lambda engine
    • [x] GH-964 | VSO-720596 | DevCom-367683 | <functional>: Passing an object with an explicit alignment that owns a std::function by value leads to invalid free on x86

    :smile_cat: Fixed

    • [x] VSO-454466 | DevCom-246251 | <scoped_allocator>: std::scoped_allocator_adaptor does not properly construct inner allocator
    • [x] GH-785 | VSO-507908 | DevCom-125537 | <complex>: Passing a double to std::arg returns wrong result.
    • [x] GH-940 | VSO-109266 VSO-366115 VSO-1141492 | DevCom-1075574 DevCom-246260 DevCom-1075573 | <valarray>: slice_array's copy ctor is missing, the same with mask_array, gslice_array, indirect_array
    • [x] GH-950 | VSO-115939 | DevCom-421634 | <random>: piecewise_linear_distribution is still broken
    • [x] GH-1069 | VSO-718901 | DevCom-369081 | <filesystem>: Use of std::filesystem::path causes link error on UWP
    • [x] GH-1161 | VSO-1166791 | DevCom-1134328 | MSVC fails to compile (C2666) simple std::stack<Class *> for x64 while for x86 it works fine

    :heavy_check_mark: Done

    • [x] GH-186 | VSO-1151642 | DevCom-1080802 | STL: Finish supporting /Wall
    • [x] GH-388 | VSO-485517 | DevCom-320893 DevCom-102668 DevCom-290124 DevCom-859581 | <streambuf>: basic_streambuf doesn't support 64-bit properly
    • [x] GH-412 | VSO-678119 | DevCom-329394 | <locale>: Eagerly-allocated facets in non-default std::locale can lead to ODR violation between DLL-exported version and header version
    • [x] GH-942 | VSO-207715 | DevCom-813352 DevCom-238607 DevCom-329888 | <array>: std::array<T,0> doesn't compile - when type is not default constructible
    • [x] GH-943 | VSO-146139 | DevCom-241515 | <iterator>: checked_array_iterator/unchecked_array_iterator should have conversions
    • [x] GH-944 | VSO-370548 VSO-257790 | DevCom-246365 DevCom-140618 DevCom-9505 | <iomanip>: get_time should parse format without delimiters
    • [x] GH-946 | VSO-685103 | DevCom-334696 | <mutex>: change mutex to be an SRWLOCK
    • [x] GH-948 | VSO-1006425 | DevCom-785027 | <exception>: std::exception::what has wrong signature
    • [x] GH-949 | VSO-620282 | DevCom-256895 | <future>: std::async with std::launch::async policy does not behave as if in new thread in regards to thread_local
    • [x] GH-952 | VSO-671111 | DevCom-317991 | <functional>: std::is_convertible is broken for std::bind functors
    • [x] GH-953 | VSO-715060 | DevCom-364060 | <valarray>: VS doesn't trigger the assertion when the data out of bound in std::valarray
    • [x] GH-955 | VSO-947547 | DevCom-642475 | <execution>: Including with /clr enabled results in compiler error.
    • [x] GH-966 | VSO-729275 | DevCom-380760 | <memory>: _msize & std::allocator don't work together
    • [x] GH-990 | VSO-725649 | DevCom-376072 | <any>: std::any doesn't link when exceptions are disabled
    • [x] GH-992 | VSO-273702 | DevCom-984204 | <regex> mishandles locale-based character classes outside of the char range
    • [x] GH-993 | VSO-287844 | DevCom-230267 DevCom-246258 | <regex>: c++ regex character class case insensitive search problem
    • [x] GH-994 | VSO-660624 | DevCom-306176 | <regex>: Regex erroneously returns a match
    • [x] GH-995 | VSO-673897 | DevCom-322328 | <regex>: basic_regex wants regex_traits to provide things not required by [re.req]
    • [x] GH-996 | VSO-678814 | DevCom-326044 | <regex>: regex_search behaves incorrectly when the regex contains R"(\[)"
    • [x] GH-997 | VSO-1054746 | DevCom-885115 | <regex>: Grouping within repetition causes regex stack error
    • [x] GH-1000 | VSO-976509 | DevCom-717452 | <random>: Floating-point random number generation suboptimal due to generate_canonical()
    • [x] GH-1001 | VSO-923008 | DevCom-606865 | <random>: binomial_distribution is broken
    • [x] GH-1002 | VSO-729899 | DevCom-381099 | <random>: The <random> header still provides the uniform_int and uniform_real class templates
    • [x] GH-1003 | VSO-486661 | DevCom-86909 | <random>: std::normal_distribution four times slower than the corresponding boost version
    • [x] GH-1004 | VSO-1142061 | DevCom-1076807 | <regex>: Error C2664 in std::regex_traits::transform
    • [x] GH-1006 | VSO-592348 | DevCom-222276 | <algorithm>: std::min_element() assumes the elements in the range are not modified
    • [x] GH-1023 | VSO-586319 | DevCom-216960 | <deque>: std::deque::insert performance
    • [x] GH-1033 | VSO-679264 | DevCom-330322 | <locale>: Empty locale name and UTF-8 issues
    • [x] GH-1035 | VSO-466800 VSO-470756 | DevCom-77779 DevCom-246249 | <string>, <vector> Debug version of STL is not exception safe and causes terminate() to be called under low memory
    • [x] GH-1036 | VSO-399383 VSO-851210 | DevCom-33006 DevCom-536767 | <deque> : A deque<T> where T is move-only, when nested in vector, does not compile
    • [x] GH-1037 | VSO-951679 | DevCom-657074 | <xtree>: _Tree move constructor incorrectly swaps
    • [x] GH-1040 | VSO-961527 | DevCom-671799 | <chrono>: No diagnostic for truncating conversion of chrono duration
    • [x] GH-1041 | VSO-636498 | DevCom-275079 | <vector>: VS 2019 ignores explicit keyword
    • [x] GH-1066 | VSO-470455 | DevCom-246248 | <xlocinfo>: Mismatched call to free when malloc is replaced with user implementation
    • [x] GH-1068 | VSO-811511 | DevCom-471144 | <locale>: Cannot run in Release mode and throw unhandled exception: std::runtime_error - UTF8 to GBK
    • [x] GH-1070 | VSO-643625 | DevCom-279568 | C++/CLI & Inconsistent layout information in duplicated types (std._Tree_unchecked_const_iterator)
    • [x] GH-1071 | VSO-368195 VSO-713785 | DevCom-246363 DevCom-18311 DevCom-362423 | <iomanip>: std::get_time asserts with "istreambuf_iterator is not dereferenceable" when format is longer than the stream
    • [x] GH-1074 | VSO-253526 | DevCom-110322 | <random>: uniform_real_distribution<float> generates numbers outside of the interval
    • [x] GH-1121 | VSO-429255 | DevCom-215436 DevCom-246252 DevCom-51443 | <locale>: std::ctype<char>::blank return true for all space-characters
    • [x] GH-1125 | VSO-847068 | DevCom-520472 | <iostream>: hexfloat stream output does not ignore precision as it should
    • [x] GH-1126 | VSO-596742 | DevCom-229445 | <iomanip>: Case sensitivity when parsing months
    • [x] GH-1171 | VSO-275515 VSO-425342 | DevCom-858136 DevCom-246367 | <fstream>: ifstream putback is still broken
    • [x] GH-1175 | VSO-620209 VSO-622201 | DevCom-256346 DevCom-260195 | <locale>: locale initialization incorrect in debug mode
    documentation resolved 
    opened by StephanTLavavej 59
  • Determine ABI stability timeline for C++20

    Determine ABI stability timeline for C++20

    We're in a novel situation: never before have we completed a Standard so rapidly. Adding to this concern, <format> is both ABI-sensitive and performance-sensitive, and WG21 is expected to mandate ABI-breaking changes soon.

    (C++17 was different; we finished <charconv> in 2019 having completed all other features much earlier, and while it was performance-sensitive, we had time to extensively test and tune it, and its function-oriented nature means that it has no ABI concerns and can be revised in the future.)

    We were initially planning to declare ABI stability when finishing C++20 (along with the addition of /std:c++20 as distinct from the always-experimental /std:c++latest), to align with the user expectation that non-experimental features supported for production use are also ABI stable. However, if this locks us into an implementation that can't keep up with retroactive changes to C++20, or freezes an implementation before it's had a chance for significant performance tuning, that will ultimately be harmful to users.

    We should consider asking our bosses and boss-like entities for a change of plans: we will still declare C++20 to be feature-complete and ready for production use when we're done (as indicated by the feature-test macros), but we can announce that its ABI will potentially change for some defined period of time (3 months, 6 months, 1 year?) or number of releases (e.g. Dev17 17.x for some specific value of X). This will have no effect for /std:c++14 and /std:c++17 users, and we can expect that, at least initially, the population of /std:c++20 users will be the most eager upgraders for whom rebuilding the world is the least onerous.

    Additionally, to mitigate mix-and-match problems, we could add a #pragma detect_mismatch to <format> right now, allowing us to revise it in the future and have the linker detect any OBJ/static LIB mixing.


    Update: We arrived at a plan, see the comment below.

    fixed high priority format 
    opened by StephanTLavavej 53
  • Build in Azure Pipelines with cached vcpkg artifacts

    Build in Azure Pipelines with cached vcpkg artifacts

    Please note that acceptance of community PRs will be delayed while we are bringing our test and CI systems online. For more information, see the README.md.

    Description

    I hope this PR is either useful and could be an inspiration on how to set up a CI system. This PR is not meant to be merged as is, but it is created in order to show how it is possible to run a build using CMake and Ninja with cached vcpkg artifacts on Hosted Build Agents.

    Hosted agents do not have the required MSVC 14.23, hence the build also install that toolset on the fly (considerably increasing build time).

    The build time on Hosted agents with cached vcpkg artifacts is about:

    • restoring cache 30 seconds;
    • building 4 minutes.
    • building vcpkg artifacts 15 minutes;

    See here for all build samples.

    No tests are run.

    Also, this PR shows how to explicitly define which vcpkg version is to be used by using a git submodule.

    Checklist:

    • [ ] I understand README.md.
    • [ ] The STL builds and test harnesses have passed (must be manually verified by an STL maintainer before CI is online, leave this unchecked for initial submission).
    opened by lukka 48
  • Misc constexpr

    Misc constexpr

    Description

    This addresses parts of #50 now that is_constant_evaluated has been implemented and we can proceed. I did not add the feature test macros fo functional and array as the larger parts are still open.

    Note that there was one prexisting bug with the constructor of insert_iterator that missed the explicit keyword

    Also tuple is hell...

    Fixes #203.

    Checklist

    Be sure you've read README.md and understand the scope of this repo.

    If you're unsure about a box, leave it unchecked. A maintainer will help you.

    • [x] Identifiers in product code changes are properly _Ugly as per https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
    • [ ] The STL builds successfully and all tests have passed (must be manually verified by an STL maintainer before automated testing is enabled on GitHub, leave this unchecked for initial submission).
    • [x] These changes introduce no known ABI breaks (adding members, renaming members, adding virtual functions, changing whether a type is an aggregate or trivially copyable, etc.).
    • [x] These changes were written from scratch using only this repository, the C++ Working Draft (including any cited standards), other WG21 papers (excluding reference implementations outside of proposed standard wording), and LWG issues as reference material. If they were derived from a project that's already listed in NOTICE.txt, that's fine, but please mention it. If they were derived from any other project (including Boost and libc++, which are not yet listed in NOTICE.txt), you must mention it here, so we can determine whether the license is compatible and what else needs to be done.
    cxx20 
    opened by miscco 46
  • <span> does not have standard layout

    does not have standard layout

    I appreciate that <span> is not required to have standard layout, however every other <span> implementation does have standard layout: libstdc++'s, libc++'s, and all the third party library implementations that I am aware of. Except for Microsoft's.

    I assume that as usual the ABI ship has sailed, so this will be a wontfix. However, fixing this would be great. Lots of code passes spans to non-C++ code, and not having avoidable UB here would be nice.

    enhancement fixed 
    opened by ned14 41
  • Implement <source_location>

    Implement

    Description

    This PR is blocked until issues with the compiler builtins are solved (as well as consteval?)

    So after now being able to run the tests there's some more potential oddities I found. Thought may as well open a draft PR as it might be helpful for compiler devs.

    So following what I found in #54.

    • Tests 17 and 18 fail the column number asserts except when current() is used as a default argument (i.e. 1st argument test, sloc, and lambda pass)
    •  source_location::current();
       ^
       source_location::current();
                        ^
      
      When used as a lambda capture the column number is the first otherwise the second.

    Issues to resolve

    • [ ] consteval source_location::current()
    • [ ] constexpr __builtin_FILE() and __builtin_FUNCTION()
    • [ ] Consistent column number location (lambda_test())
    • [ ] Column number when not a default argument under tests 17 and 18
    • [x] Column number with tabs
    • [x] sub_member_test()
    • [x] ~~NTTP test~~

    I'm unsure how to test the tab column issue as that would mean this file fails validation, right? Thought maybe put it in a different file with a file extension that could be skipped e.g. test.tab?

    Is using ends_with sufficient for the file name tests?

    Checklist

    Be sure you've read README.md and understand the scope of this repo.

    If you're unsure about a box, leave it unchecked. A maintainer will help you.

    • [x] Identifiers in product code changes are properly _Ugly as per https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
    • [ ] The STL builds successfully and all tests have passed (must be manually verified by an STL maintainer before automated testing is enabled on GitHub, leave this unchecked for initial submission).
    • [x] These changes introduce no known ABI breaks (adding members, renaming members, adding virtual functions, changing whether a type is an aggregate or trivially copyable, etc.).
    • [x] These changes were written from scratch using only this repository, the C++ Working Draft (including any cited standards), other WG21 papers (excluding reference implementations outside of proposed standard wording), and LWG issues as reference material. If they were derived from a project that's already listed in NOTICE.txt, that's fine, but please mention it. If they were derived from any other project (including Boost and libc++, which are not yet listed in NOTICE.txt), you must mention it here, so we can determine whether the license is compatible and what else needs to be done.
    cxx20 
    opened by SuperWig 41
  • Optimize random

    Optimize random

    Description

    Applied the multiply-shift optimization described by Daniel Lemire (https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/ which also refers to arXiv:1805.10941v4).

    Note that the the bias-check was changed. The _Ret/_Index calculation seemed to be optimized in a way that it could easily return _Ret%_Index, making the modulo itself relatively cheap. For a sample testcase, which I compared to the original implementation as baseline, I found that only applying multiply-shift is around 1.1 times faster. Changing the check to _Ret < (_Mask - _Mask % _Index) in addition to the optimization showed to be 1.5 times faster. To be safe I also tried keeping the modulo operation and used just the modified bias-check, which was 1.2 only times faster than the baseline.

    In the spirit of removing modulo operations, I also replaced the check _Mask % _Index == _Udiff(_Index - 1) (if _Index is a power of 2) with a check that does not rely on modulo operations.

    Fixes #178.

    Checklist

    Be sure you've read README.md and understand the scope of this repo.

    If you're unsure about a box, leave it unchecked. A maintainer will help you.

    • [x] Identifiers in product code changes are properly _Ugly as per https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
    • [x] The STL builds successfully and all tests have passed (must be manually verified by an STL maintainer before automated testing is enabled on GitHub, leave this unchecked for initial submission).
    • [x] These changes introduce no known ABI breaks (adding members, renaming members, adding virtual functions, changing whether a type is an aggregate or trivially copyable, etc.).
    • [ ] These changes were written from scratch using only this repository and the C++ Working Draft as a reference (and any other cited standards). If they were derived from a project that's already listed in NOTICE.txt, that's fine, but please mention it. If they were derived from any other project (including Boost and libc++, which are not yet listed in NOTICE.txt), you must mention it here, so we can determine whether the license is compatible and what else needs to be done.
    performance 
    opened by chris0x44 41
  • `<vector>`: Add ASan annotations.

    ``: Add ASan annotations.

    Add ASan container annotations to vector. This should allow ASan to catch additional errors when using vector. Specifically this will catch accesses from [v.data() + v.size(), v.data() + v.capacity()) which would otherwise be missed as they are legal memory addresses.

    Closes #2030

    enhancement high priority 
    opened by cbezault 37
  • `<ranges>`: `elements_view::iterator::iterator_category` invokes the `operator*() &&` of the underlying iterator

    ``: `elements_view::iterator::iterator_category` invokes the `operator*() &&` of the underlying iterator

    https://github.com/microsoft/STL/blob/b812b0e22b6e2a777800c6080ab636d70aec0678/stl/inc/ranges#L4982-L4989

    Should _STD declval<iterator_t<_Base>>() be _STD declval<iterator_t<_Base>&>()?

    #include <ranges>
    
    struct I {
      using difference_type = std::ptrdiff_t;
      using value_type = std::pair<int, double>;
      value_type& operator*() const &;
      void operator*() && = delete;
      I& operator++();
      I operator++(int);
      bool operator==(const I&) const;
    };
    
    int main() {
      std::ranges::input_range auto r = std::ranges::subrange(I{}, std::unreachable_sentinel);
      auto e = r | std::views::keys;
    }
    

    https://godbolt.org/z/oW8dP56zv

    opened by hewillk 0
  • <locale>: Unnecessary locking around classic locale

    : Unnecessary locking around classic locale

    When retrieving the classic locale the current code calls _Init which takes a lock regardless of initialization state.

    Expanded here, the code looks like the following.

    _MRTIMP2_PURE const locale& __CLRCALL_PURE_OR_CDECL locale::classic() { // get reference to "C" locale
        //_Init();
        {
              locale::_Locimp* ptr = nullptr;
          
              _BEGIN_LOCK(_LOCK_LOCALE) // prevent double initialization
          
              // this function just returns a global variable
              // ptr = _Getgloballocale();
              ptr = global_locale;
          
              if (ptr == nullptr) { // create new locales
                  _Setgloballocale(ptr = _Locimp::_New_Locimp());
                  ptr->_Catmask = all; // set current locale to "C"
                  ptr->_Name    = "C";
          
                  _Locimp::_Clocptr = ptr; // set classic to match
                  _Locimp::_Clocptr->_Incref();
                  ::new (&classic_locale) locale(_Locimp::_Clocptr);
              }
          
              // this is always false in the classic() codepath
              //if (_Do_incref) {
              //    ptr->_Incref();
              //}
          
              _END_LOCK()
              //return ptr;
        }
        return classic_locale;
    }
    

    This means that every call to classic() is locking and unlocking a mutex, despite that after its initialization the pointer must always be valid. This can cause huge performance issues in specific scenarios, for example https://twitter.com/aras_p/status/1558063800145813505 shows a measured ~500x performance penalty in some blender loading code due to contention on this lock.

    A fast path that avoids locking (by checking whether global_locale is valid, and directly returning before entering the critical section) should drastically improve performance in this and other similar situations.

    https://github.com/microsoft/STL/blob/5e7cac7f679/stl/src/locale0.cpp#L138-L141

    opened by jsimmons 0
  • `<iterator>`: `ranges::prev` maybe ill-formed in debug mode

    ``: `ranges::prev` maybe ill-formed in debug mode

    https://github.com/microsoft/STL/blob/5aae6780236208577b4e8a000cbe7aa3cbc24c41/stl/inc/xutility#L2636-L2648

    ranges::prev uses _Min_possible_v to detect integer overflow, whereas _Min_possible_v uses make_unsigned_t which doesn't work with integer-class types.

    #define _DEBUG
    #include <ranges>
    
    int main() {
      auto r = std::views::iota(0ull, 5ull);
      auto it = r.end();
      auto prev = std::ranges::prev(it, 3);
    }
    

    https://godbolt.org/z/4GzPo1nzc

    bug ranges 
    opened by hewillk 1
  • `<string>`: `string::substr` forward the allocator to the newly created `string`

    ``: `string::substr` forward the allocator to the newly created `string`

    The C++ Standard doesn't say that: https://eel.is/c++draft/string.substr

    https://github.com/microsoft/STL/blob/5aae6780236208577b4e8a000cbe7aa3cbc24c41/stl/inc/xstring#L4673-L4676

    @CaseyCarter agreed. He also assumed that we'll fix this when implementing P2438 but I still decided to create an issue to not forget about it.

    LWG issue needed 
    opened by fsb4000 3
  • `<ranges>`: list-initialization is misused

    ``: list-initialization is misused

    Non-list-initialization (parentheses) and list-initialization (curly braces) styles are mixed in the <ranges>, however, the latter does not provide any observable benefit and may bring potential issues. We should use non-list-initialization consistently, as the standard does.

    #include <ranges>
    #include <initializer_list>
    #include <utility>
    
    struct I {
      using difference_type = int;
      using value_type = int;
      I(std::initializer_list<int*>) = delete;
      I(int*);
      int operator*() const;
      I& operator++();
      I operator++(int);
    };
    
    struct R {
      int* begin();
      I begin() const;
      std::unreachable_sentinel_t end() const;
    };
    
    int main() {
      auto r = R{} | std::views::transform(std::identity{});
      decltype(std::as_const(r).begin()) c = r.begin();
    }
    

    https://godbolt.org/z/89eo678qd

    bug ranges 
    opened by hewillk 2
Owner
Microsoft
Open source projects and samples from Microsoft
Microsoft
Libft is an individual project at 42 that requires us to re-create some standard C library functions including some additional ones that can be used later to build a library of useful functions for the rest of the program.

?? Index What is Libft? List of Functions Technologies ✨ What is Libft? Libft is an individual project at 42 that requires us to re-create some standa

Paulo Rafael Ramalho 7 Jan 17, 2022
Thrust is a C++ parallel programming library which resembles the C++ Standard Library.

Thrust: Code at the speed of light Thrust is a C++ parallel programming library which resembles the C++ Standard Library. Thrust's high-level interfac

NVIDIA Corporation 4.1k Aug 15, 2022
jkds is a modern header-only C++20 library that complements the standard library.

jkds is a modern header-only C++20 library that complements the standard library. It provides generic atypical data structures, ergonomic functional programming abstractions, and then some.

Alberto Schiabel 5 May 24, 2022
Bionic BSD-3-ClauseBionic - Google's standard library, developed for Android. BSD-3-Clause

bionic bionic is Android's C library, math library, and dynamic linker. Using bionic as an app developer See the user documentation. Working on bionic

Android Open Source Project 548 Jul 31, 2022
CloudABI's standard C library

NOTE: This project is unmaintained CloudABI is no longer being maintained. It was an awesome experiment, but it never got enough traction to be sustai

Nuxi 272 Jun 7, 2022
libcu++: The C++ Standard Library for Your Entire System

libcu++, the NVIDIA C++ Standard Library, is the C++ Standard Library for your entire system. It provides a heterogeneous implementation of the C++ Standard Library that can be used in and between CPU and GPU code.

NVIDIA Corporation 2k Aug 8, 2022
EASTL stands for Electronic Arts Standard C++ Template Library

EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

Electronic Arts 6.6k Aug 8, 2022
An open source standard C library that includes useful functions && (Reimplementation of libc functions + own functions).

?? LIBFT-42 : Artistic view of LIBC: ?? HOW DOES IT FEEL HAVING YOUR OWN LIB: SUBJECT : ENGLISH PDF ℹ️ What is LIBFT : This project aims to code a C l

Abdessamad Laamimi 10 Mar 24, 2022
Your standard library for metaprogramming

Boost.Hana Your standard library for metaprogramming Overview #include <boost/hana.hpp> #include <cassert> #include <string> namespace hana = boost::h

Boost.org 1.4k Aug 1, 2022
Reimplementation of some of the Standard C Library functions.

42-libft Reimplementation of some of the Standard C Library functions. This repository contains some of the standard library C functions. List of avai

Lavrenova Maria 5 Jan 26, 2022
STXXL: Standard Template Library for Extra Large Data Sets

STXXL is an implementation of the C++ standard template library STL for external memory (out-of-core) computations

STXXL 428 Jul 25, 2022
mlibc is a C standard library

mlibc is a C standard library Official Discord server: https://discord.gg/7WB6Ur3 Design of the library Directory Purpose options/ (More or less) OS-i

The Managarm Project 511 Aug 4, 2022
Windows Implementation Library

Windows Implementation Libraries (WIL) The Windows Implementation Libraries (WIL) is a header-only C++ library created to make life easier for develop

Microsoft 2k Aug 11, 2022
42 Cursus - Libft: My implementation of some useful C functions and some additional ones to use it in future projects of 42.

42 Cursus - libft Info My implementation of some useful C functions and some additional ones to use it in future projects of 42. Status: still updatin

izenynn 7 Jul 21, 2022
A size-optimized STL implementation.

uSTL This library is obsolete. Please use the official gcc C++ standard library. uSTL is a partial implementation of the C++ standard library that foc

Mike Sharov 399 Jul 9, 2022
Library that simplify to find header for class from STL library.

Library that simplify to find header for class from STL library. Instead of searching header for some class you can just include header with the class name.

null 6 Jun 7, 2022
D++ Extremely Lightweight C++ Discord Library

D++ An incredibly lightweight C++ Discord library This project is in alpha stages of development. Completed so far: Websocket connection with heartbea

brainbox.cc 441 Aug 10, 2022
Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags.

Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags. Quick start #include <bitflags/bitf

Marin Peko 71 Jul 30, 2022
expected lite - Expected objects in C++11 and later in a single-file header-only library

expected lite: expected objects for C++11 and later expected lite is a single-file header-only library for objects that either represent a valid value

Martin Moene 221 Aug 5, 2022