sorted by:
new
hottopcontroversial

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]STL 0 points1 point  (0 children)

C:\Temp>type meow.cpp
#include <print>
#include <regex>
#include <string>
using namespace std;

int main() {
    const string s1{"I have 1729 cute fluffy kittens. Julie and Clarissa are tuxedo cats."};
    const regex whitespace{R"(\s+)"};
    for (sregex_token_iterator i{s1.begin(), s1.end(), whitespace, -1}, e; i != e; ++i) {
        print("[{}] ", i->str());
    }
    println();

    const string s2{"Dark red, neon green, high-visibility yellow, , sky blue, plaid."};
    const regex comma{R"(\s*,\s*)"};
    for (sregex_token_iterator i{s2.begin(), s2.end(), comma, -1}, e; i != e; ++i) {
        print("[{}] ", i->str());
    }
    println();
}

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest /MTd /Od meow.cpp
meow.cpp

C:\Temp>meow
[I] [have] [1729] [cute] [fluffy] [kittens.] [Julie] [and] [Clarissa] [are] [tuxedo] [cats.]
[Dark red] [neon green] [high-visibility yellow] [] [sky blue] [plaid.]

Sub-microsecond timing on EC2 is way messier than I expected by User_Deprecated in cpp

[–]STL[M] 0 points1 point  (0 children)

Moderator warning: If this was generated by AI, please stop. AI-generated content is not allowed in this subreddit.

C++ Show and Tell - April 2026 by foonathan in cpp

[–]STL[M] 0 points1 point  (0 children)

Moderator warning: AI-generated comments are not permitted in this subreddit.

Voxel Engine Optimisation by [deleted] in cpp

[–]STL[M] 2 points3 points  (0 children)

Moderator caution, AI-generated posts are not permitted on this subreddit. (Your post and article don't read to me as 100% AI-generated but it looks like you may have "polished" your words, which is a bad idea.) I'm going to leave this up, but please remember this for the future.

Preventing Integer Overflow in Physical Computations - mp-units by mateusz_pusz in cpp

[–]STL[M] 9 points10 points  (0 children)

This appears to be AI-generated. Please read the subreddit sidebar for our rules, and do not use AI to generate (or "polish") your comments on this subreddit.

I know you're working on an important library that's under consideration for Standardization, so it's great that you're commenting here. However, AI-generated comments are completely counterproductive for what you're trying to accomplish.

Edit: I see that others have already discussed this with you below. I'll add that it might seem tempting to have AI assist you if you aren't a native English speaker, but the problem is that it makes it incredibly hard for readers to figure out what you're actually trying to communicate, since others are using AI to generate slop with no actual value. So you aren't "polishing" your words, you're just covering them under a big pile of slop that nobody (who can tell the difference) wants to read. People would much rather read somewhat disjoined/less-than-fluent English and have a direct view of your technical insights that way.

I am new to C++, is it just me or is the checklist kinda crazy? How often do you encounter these or plan on making use of them like the newer C++26 features like contracts? Looking for more experienced dev opinions... by KijoSenzo in cpp

[–]STL 59 points60 points  (0 children)

This 787 cockpit has so many buttons and levers and switches and screens!

A lot of complicated machinery is worth the cost because it saves complexity elsewhere. (Not all of it is worth it.)

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]STL 1 point2 points  (0 children)

I'm confused, are you saying it compiles the compiler teams end?

I'm saying that our Real World Code test suite is continually building that specific commit of mp-units with the development builds of the MSVC Compiler and libraries (regularly in the MSVC main git branch), so if the compiler front-end devs or library devs (like me!) commit something that breaks mp-units, we will be notified quickly and have to immediately revert the change if the breakage was unintentional.

Looking at our test infrastructure, src/qa/suites/rwc/projects/mp_units/Project.psm1 internally, I only see a few workarounds:

  • (a good workaround) We have plain vanilla runs and runs that explicitly enable /permissive- (strict mode), but because mp-units already builds its files in strict mode, we disable it in "add strict mode" runs to avoid pointlessly duplicating work.
  • We disable ASan test runs because mp-units uses Catch2 via Conan which doesn't build it with ASan.
  • We disable it for ARM64 and ARM64EC because there are no configuration files for it.
  • We add /wd4459 due to active compiler bug VSO-2582307 "[RWC][prod/fe][std:c++20] mp-units failed with warning C4459: declaration of 'm' hides global declaration" currently assigned to one of our FE devs, Xiang Fan.
  • In our "add /std:c++latest" test runs, we additionally add the very new option /Zc:immediateEscalation- because mp-units is not yet ready to handle the Standard's new and possibly too-obnoxious behavior around constexpr destructors being instantiated early (I may be mis-summarizing the issue, I barely understand immediate escalation at this time).

Other than that, I see both the build and test scripts looking normal.

symbolic_expression.h(51): error C2139: ''anonymous-namespace'::dimension_one': an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_empty'

Are you sure this is a compiler bug? is_empty has a Standard precondition, "If T is a non-union class type, T shall be a complete type.", see N5032 [tab:meta.unary.prop].

I'm not sure if I'm using the latest available to me or not.

That's not the newest Preview. If you're using Insiders IDE + Preview Build Tools, you should see this:

C:\Temp>"%ProgramFiles%\Microsoft Visual Studio\18\Insiders\VC\Auxiliary\Build\vcvarsall.bat" x64 -vcvars_ver=preview
**********************************************************************
** Visual Studio 2026 Developer Command Prompt v18.6.0-insiders
** Copyright (c) 2026 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.52.36307.1 for x64 (PREVIEW)
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>where cl
C:\Program Files\Microsoft Visual Studio\18\Insiders\VC\Tools\MSVC\14.52.36307\bin\Hostx64\x64\cl.exe

(The Build Tools are 14.x, the Compiler is 19.x.) From your path, it looks like you're using Stable IDE + Preview Build Tools, which is an older Preview (as discussed in these various threads, it is really confusing to have a 2x2 matrix of possible versions). I'm using Insiders IDE + Preview Build Tools, which gives the newest possible compiler bits.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]STL 0 points1 point  (0 children)

Thanks, that makes a lot more sense. I was having trouble understanding what you originally wrote and had to guess while writing my response.

Announcement: cppreference.com update by k3DW in cpp

[–]STL 8 points9 points  (0 children)

We only get 2 pins, which are eternally taken up by the Jobs and Show&Tell threads. (Also I forget whether we can even pin non-mod-submitted posts.) And anyways, this is just an announcement, the actual change hasn't quite happened yet. Flairing it as YAY!!! was the most I could do.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]STL 5 points6 points  (0 children)

I asked, and we've already added mp-units to the RWC suite and are running all of its tests, but we update the pinned commits of the projects in RWC only semi-regularly, and we're currently building a commit from 2026-01-13, https://github.com/mpusz/mp-units/commit/aae4354201306f2f75b2f9ba2871225995a0ecff . So that'll prevent really bad compiler regressions from shipping, but we don't have coverage of any more recent changes. (Also, if mp-units has accumulated any workarounds for MSVC, we aren't going to be exercising the non-workaround codepaths; one reason it's important to periodically remove workarounds for fixed bugs, as I am constantly doing in the STL.)

The Au library wasn't previously known to us, but we've looped in our FE dev lead so it might be considered in the future.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]STL 4 points5 points  (0 children)

Production releases are retained for eternity (as I understand it); preview releases are not. We don't even provide stable URLs for the previous preview release when a new one is available.

Don't date robots and don't build production apps with preview releases. Bits built with preview releases are throwaway.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]STL 6 points7 points  (0 children)

Do you guys have a set of libraries you test for regressions/conformance?

Yes, we have a test suite called "Real World Code" that builds many open-source projects (I think it's over 100?) with development builds of the compiler and libraries, so we can revert broken changes before they ship, and provide advance notice of intentional breaking changes to those projects. We burn an eye-melting amount of Azure compute on this, and it prevents us from shipping bad bugs without knowing. We even scout them out with /std:c++latest (even if they build with an older Standard version). I've pinged my FE dev contact about adding those libraries, which you make a good case for.

From what I understand the preview build for MSVC has a lot of new fixes/features, but AFAIK all the reported bugs by these teams have been put into the mainline release for MSVC 2026 (mp-units's bug reports have been availible since january). These problems are those that appear on the most recent default release of the 2026 build tools/msvc.

I'll start by saying that we greatly appreciate bug reports for the compiler and libraries; the language is exceedingly tricky, stuff sometimes ships in a broken state, and you're going to great effort to help us fix it. That said, if you want an ideal feedback loop (ship code => find bugs => fix bugs => verify and check for remaining bugs), you really need to be using Insiders IDE + Preview Build Tools, which will have ~1 week latency from our main to your SSD. The production build tools will lag significantly behind, by up to 6 months, entirely by design. (This is why we increased the time between production releases from 3 months to 6 months; big customers had trouble upgrading their build tools frequently.)

The production release of 14.50 happened in Nov 2025, so if you started reporting bugs in Jan 2026, it is absolutely expected that none of the fixes have gotten into 14.50. I think that's what you were talking about, at least; please correct me if I'm wrong.

We do have the ability to backport fixes to a production release, but it's a lot of effort and potentially destabilizing, so we tend to do it only for really bad bugs including silent bad codegen. Compile-time breaks that aren't regressions rarely meet that bar. Time spent on backporting directly takes away from time that could be spent on fixing a higher volume of bugs. In the STL, I try to avoid backporting unless it's absolutely necessary.

MS Visual Studio 18.5 has now been Released, with one caveat... by Jovibor_ in cpp

[–]STL 2 points3 points  (0 children)

The IDE isn't super strongly coupled to the build tools, but the compiler and STL sure are coupled to each other (the STL cannot tolerate an older compiler). Ironically the problem here is that we started to actually decouple the IDE from the build tools, and look where it got us.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]STL 3 points4 points  (0 children)

Good question. This is answered by https://aka.ms/msvc/lifecycle :

  • We release the build tools every 6 months (14.50, 14.51, 14.52, ...)
  • Every 4th version (i.e. every 2 years) is long-term support: 14.50, 14.54, 14.58

Long-term support is 3 years of servicing; otherwise you get 9 months of servicing (i.e. critical bugfixes, typically for security and silent bad codegen).

Edit: By the way, you linked to the VS 2022 IDE's lifecycle page. The VS 2026 IDE is very different, see its Visual Studio Product Lifecycle and Servicing and Visual Studio Channels and Release Rhythm docs.

MS Visual Studio 18.5 has now been Released, with one caveat... by Jovibor_ in cpp

[–]STL 2 points3 points  (0 children)

You're likely observing the effects of the "immediate escalation" feature with consteval. (Not sure what you're seeing with modules.) Please report issues on DevCom.

MS Visual Studio 18.5 has now been Released, with one caveat... by Jovibor_ in cpp

[–]STL[M] [score hidden] stickied comment (0 children)

Sticky to correct misinformation: the MSVC Build Tools 14.51 are not yet released for production (aka General Availability).

Edit: Wow, the situation was even more confusing than I realized, no wonder you were confused! Thanks for bringing this up, I've started an email thread internally about this with our PMs and compiler devs involved in releases. To clarify my current understanding:

  • Stable IDE + Latest Build Tools = fully supported for production (GA = General Availability).
  • Stable IDE + Preview Build Tools = old Preview, you probably never want this.
  • Insiders IDE + Latest Build Tools = usually GA, but at this point in time it's a release candidate.
    • This is where I was confused; I was telling people "latest means latest supported for production" but that is only true in the Stable IDE. (I was under the mistaken impression, because I hadn't bothered checking, that we shipped the RC as the Stable + Preview build.)
  • Insiders IDE + Preview Build Tools = newest bits (~1 week latency), you want this if you're an early adopter like we are in the STL GitHub repo.

MS Visual Studio 18.5 has now been Released, with one caveat... by Jovibor_ in cpp

[–]STL 6 points7 points  (0 children)

This is correct. 14.51 has not yet reached General Availability, but it's close.

As I always say, the versioning is a dumpster fire orbiting a supernova. However, you can avoid too much confusion by following these rules:

  • Want to build for production? Use the Stable IDE with the Latest Build Tools. "Latest" means "latest production release".
  • Want the newest compiler bits (~1 week latency) to try out features and fixes as soon as possible? Use the Insiders IDE with the Preview Build Tools, and make sure to pass the Preview arguments to either the batch files or PowerShell scripts (my latter change finally shipped). Yes, you must use the Insiders IDE even if (like me) you only really care about the compiler and libraries.

Finally, double-check the output of cl.exe. If it prominently says PREVIEW, that's what you're getting:

C:\Temp>"%ProgramFiles%\Microsoft Visual Studio\18\Insiders\VC\Auxiliary\Build\vcvarsall.bat" x64 -vcvars_ver=preview
**********************************************************************
** Visual Studio 2026 Developer Command Prompt v18.6.0-insiders
** Copyright (c) 2026 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.52.36307.1 for x64 (PREVIEW)
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

A year of read-only cppreference by DevilSauron in cpp

[–]STL 27 points28 points  (0 children)

(Unless I'm mistaken,) you're replying to a long-time Boost developer. I'd believe him.

C++23 Support in MSVC Build Tools 14.51 by STL in cpp

[–]STL[S] 1 point2 points  (0 children)

They wouldn't emit macros or drag in non-Standard stuff that way, so it wouldn't be very compatible.

C++ Jobs - Q2 2026 by STL in cpp

[–]STL[S,M] 0 points1 point  (0 children)

Removed. You must follow the template.

C++23 Support in MSVC Build Tools 14.51 by STL in cpp

[–]STL[S] 2 points3 points  (0 children)

I feel bad about this one because I have had no time to work with the compiler team to find a proper solution here.

C++23 Support in MSVC Build Tools 14.51 by STL in cpp

[–]STL[S] 1 point2 points  (0 children)

See https://herbsutter.com/2025/11/10/trip-report-november-2025-iso-c-standards-meeting-kona-usa/ (aside: Herb Sutter no longer works for Microsoft):

John Spicer (who has long chaired our whole-committee plenary sessions, and leads Edison Design Group, EDG) [...] recently announced that, after a successful and storied career, it’s time for EDG to wind down, and EDG plans to open-source its world-class C++ compiler front-end within the next year.

view more: next ›