CppCast - Visual C++ Announcements at CppCon 2019

Episode Date: September 26, 2019

Rob and Jason are joined by Marian Luparu, Sy Brand and Stephan T Lavavej in this special episode recorded at CppCon. They discuss some of the big announcements made by the Visual C++ team at CppCon. Including the open sourcing of MSVC's STL, adding ASAN support to Visual Studio, C++17 conformance and much more. Links Open Sourcing MSVC’s STL Intelligent Productivity and Collaboration, from Anywhere Sign up for Private Preview of Visual Studio Cloud Environments Microsoft C++ Team at CppCon 2019 Sponsors Enter #cppcast in the Message field and get a month-license instead of 7-day license PVS-Studio PVS-Studio Twitter JetBrains

Episode 216 of CppCast with guests Marion Luparu, Sai Brand, and Stephan T. Laowade recorded September 20th, 2019. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. And by JetBrains, makers of smart IDEs to simplify your challenging tasks and automate the routine ones. Exclusively for CppCast, JetBrains is offering a 25% discount for a yearly individual license, new or update, on the C++ tool of your choice. CLion, ReSharper C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at www.jetbrains.com

in this episode we sit down at CPCon with members of Microsoft's Visual C++ team. We cover some of the big announcements made by the Visual C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? Doing all right, Rob. How are you doing? Doing good. Last day of CppCon now.

It's early, early in the morning. It's not quite the last day of CppCon, because there's also post-conference classes coming up. Right, which you are giving one of? Yes. Looking forward to that already? Oh, yeah, it's a class i have given before actually and you do have one more talk today too right jason yes one more talk it'll be my third and final talk for the conference been a busy week for you okay uh well i think we should get right into introducing our guests, all of which we've had on before on the show.

Sai, would you want to start? Hi, I'm Sai. I'm the team's C++ developer advocate. So I'm in charge of editing the technical blog, a bunch of conference stuff, making sure that people can make the best of our tools. Okay, Stefan? Hi, I'm Stefan T. Lawade, and I've been working on Microsoft's STL implementation since 2007. Yeah, it's a long time. I'm Marian Loparu.

I'm the program manager lead for the C++ team. Okay, well, welcome, all of you. Just to start off, do you want to tell us how you're enjoying the conference, Marion? Oh, it's been awesome. It's been very tiring at the same time, and I have made a long list of things that I want to see also on video as well because you can never catch everything you want to see. No, there's like six tracks.

Six tracks, yeah. Let's see. It was great to have some of the people from Redmond come in here, do some very cool talks as well. Stefan did your CharConf, and we had a few exciting announcements as well. So those have gone well. So I'm pretty happy with how the conference went.

Yeah, we'll get into those announcements in a moment, but you guys have been really busy. I mean, there have been 14 talks amongst you and all the other C++ team members that are here, MSVC team members. Yeah, we're very lucky to have access and to be able to share kind of the learnings we have as we develop C++ products,

as we develop C++ tooling. And mostly, most of the learnings we have as we develop C++ products, as we develop C++ tooling. And mostly, most of the time, we're here to learn from customers what is the next challenge they have and how we can help. So the Microsoft Visual Studio team has a booth here at the conference. Also, do you have a lot of people come up

and give you suggestions or input feedback directly at the booth? Yeah, I think it's been quite a busy booth. We've been luring people with some swag to get them to talk with us, but they've been pretty open telling us about... It's good to hear the good news, the happy news about them being very happy

of using Visual Studio, Visual Studio Code. And then we had, most of the time, four or five people there from the team being able to answer questions about how to use the product, where do they get stuck. There's been emails going back to Redmond for further investigations and getting back to the people stopping by the booth. So I hope people got their questions answered. If not, we're still going to be not going anywhere. We're on Twitter, we're over email. Happy to answer all of those questions. I'm curious from the developer advocate perspective, from Psy's perspective, how important conference time is for you compared to the rest of the time?

Yeah, it's definitely all the conferences I go to are really great opportunities for people to come to me and say, hey, I have this problem or issue with the tools and I have no idea who to talk to or where to go or if I need to create a bug, where do I do that? Things like that. So it's a great opportunity to just make sure people know where to go to make their voice heard, essentially.

And if they come to me with something, I can route it through the right channels and the team and things like that. So it's just great when you're in person. It's so much lower friction than, especially, you know, like people are all around the world. Some people in the US, I'm in Scotland. So yeah, it's just a great opportunity to really make those things happen so you're saying that Twitter is not the best mechanism for communicating Twitter is Twitter is the best mechanism for

most things I think but yeah in person is great yeah just uh just yesterday I was explaining to a CP account attendee the various mechanisms we have for reporting issues with the product. Like we've got the IDE where we've got a menu option to report a problem, and that's good for some bugs. We've got developer community. Now we've got GitHub for various open source projects. And all the channels are good,

but some are more suited to some kinds of bugs than others, or suggestions. Are there any interesting projects on GitHub that Microsoft is... Ah, what a leading question. Yeah, we should jump into that. So what was the main big announcement you had for us this week? Yeah, so on Monday we announced that MSVC's STL is now open source. All the product sources,

both the headers and the separately compiled source files are available on GitHub, um, with a CMake build system, um, that's still in progress. Um, and it is under a permissive license,

the Apache two Oh license with LVM exception, which coincidentally is the exact same license that clang LVM and lib C plus plus use. Uh, we deliberately chose the same license as them, um, in the hopes that this will enable cross-pollination of code.

We like their license, and we just wanted to align with them. So is it... I believe... Okay, so the Visual Studio Standard Library should be able to compile with Clang for Windows. Can I also compile it on Linux? Ah, so we have that

covered in the READme. We do support Clang LVM as a compiler on Windows. We've done that for quite some time. It initially started when we had released the experimental Clang C2 compiler. That was Clang's front end welded to the Microsoft C2

back end. That experiment ended, and we are now using, we learned a lot from it. We helped Clang get started with emitting PDB generation. They had already started, and we gave them additional information so they could refine their PDB output. Now we actually ship Clang LLVM inbox in the Visual Studio installer. You can just select it and install Clang LLVM. And since then, we've supported compiling our STL with the Clang LLVM front end as a first class citizen. So it's not just something we occasionally test. We test it all the time on par with C1XX, Microsoft's front end. And occasionally, we even support Clang better than C1XX. Like if Clang supports features like class-temp-r deduction,

we have actually shipped STL support for the corresponding library tech active in Clang before MSVC's compiler. And it looks like that's going to happen again with is constant evaluated. So we really like Clang. And we're going to continue to support it. And we look forward to enhancing our support for Clang. But one of our current non-goals

is that we don't plan to support MSVC's STL targeting any other platforms like Linux or macOS. There are other STLs there, like LibCS Plus and LibStudCS Plus. And currently, we don't understand a case for why somebody would want to use MSVC's STL on those platforms, given that it would be inherently binary incompatible. Not that we have, you know, it would be nice, but we just don't see a reason why anyone would want to expend that energy. So that's why it's one of our non-goals. It's not that we don't want to see it happen.

If somebody wants to port our STL as a fork, they can totally do that. That's what the license allows. But we're not going to review pull requests towards that direction. I mean, I agree with you that I also don't see a business case for it. license allows. But we're not going to review pull requests towards that direction. Okay. I mean, I agree with you that I also don't see a business case for it. However, I don't know how many times this week I've heard someone say, well, the committee did X and didn't see a use case for Y yet. And now we have Y and Z and Q. Very true. We'll see what happens, I guess. So you mentioned some non-goals and you wouldn't accept pull requests from targeting linux for example but you do plan on accepting pull requests and

reviewing pull requests right oh yes um in fact we've already accepted a couple pull requests one fixing typos uh others uh one fixing um i believe there is an issue in our build system um right now um we've got the readme explaining that pull request reviews will be delayed because we're still getting our tests into GitHub, and we need to set up a CI system that's equivalent to what we have at Microsoft Internal right now. So until then, we're wary of approving pull requests on GitHub without test infrastructure and then realizing, wait, this breaks in some obscure scenario. Even changes that look almost completely correct, or as correct as we can tell, sometimes they expose compiler bugs, all compilers of bugs,

and STL changes often find them. So we do have the ability to accept pull requests, but it's through a cumbersome process of we need to replicate it in the Microsoft internal repo, run our tests, and then if that passes, then improve it on GitHub. We're trying to do as little of that as possible. We just want to switch over to GitHub as fast as possible, move all of our development there. So hopefully the transition period of we've split our tests in our product between two repositories, that'll only last maybe a month or two. I'm being a little optimistic here. But our eventual intention is for the GitHub repo to contain all the tests, all the product code, and be the single source of truth for the STL. And even if we still build it in the Microsoft

internal Git repo, that will simply be copied over from GitHub and no actual development will happen there anymore. Okay, great. And STL, you also gave a talk yesterday about what you refer to as C++17's final boss. That's right. CareConf. Can you just give us a little overview of what the final boss is? Oh, yeah. So that's the CareConf header that was added to C++17, actually back in 2016. Everybody thought it was going to be really easy to implement. And by everybody, I mean everybody on the library working group, everybody in MSVC. And it turned out to take a year and a half for MSVC. And we're the first standard library to ship it. We also, I mean, one of the reasons we're the first is also our ABI lets us do less work because

our long double is only 64 bits. Having to only implement it for 32 and 64 bit floating point is strictly less work than having to worry about 80 and 128 bit long doubles like you see on other platforms. So in some sense, we cheated because of our AVI decisions like, you know, 25 years ago, which I am very grateful for because it made my life a lot easier. And it just turned out to involve novel algorithms. I actually worked, this is one example where open source has helped us greatly. I was about to implement Kerikov.

We were looking into the literature. And at the same time, it turned out that a developer at Google, Ulf Adams, who works on Google's build system, Bazel, had in his free time just single-handedly revolutionized floating point printing. He developed a new algorithm called Roo, put it up on GitHub, and this was better than all other known algorithms.

So we are now shipping the first production implementation of that in a C++ standard library. It powers all the various forms of Kerakov that work with decimals and are printing both the Roo and RU printf algorithms. And they're blazingly fast. They're an order of magnitude faster than our CRT implementation, which itself was, you know, fairly reasonable. People have been using that for, you know, 20 years. But RU is just a gigantic step forward based on what was possible before. I think that's an interesting just commentary, right? You would think that something like string to double conversion

or whatever would be a solved problem, like there would be no new novel algorithms to discover. That's right. Yeah, because the original paper, you know, the classic Dragon 4 algorithm that was apparently floating around, known to people for a long time,

finally published in 1990, some incremental improvements, and then nothing happened for 20 years until a new algorithm, Grusu 3, was published in 2010. And then nothing significant happened for another handful of years. And it looked like, okay, maybe Grusu 3 is just, you know, the final, you know, evolution. And that's the best we can ever do, because it's a hard problem. And then out of nowhere, you know, comes Rooo. And that was just incredibly impressive to see. Wow. Do you know if some of the other std C++ libraries are also looking at using Roo?

You said MSVC was the first one to... Yeah, I've certainly been in contact with all the other STL maintainers. In fact, as I was first learning about these algorithms, I sent them an email saying, like, I'm still working on the code, but here's my understanding, you know, devoid of code at the time because we were still proprietary. And hopefully this will help you, you know, explore the problem space better. Now that we're open

source, we're looking forward to working with LibC++ if they want to adapt our implementation to their platforms. And it's possible that Libstutius Plus could also learn from our code, although we do have a license difference there. So it's unclear whether they could use our code as is. But they could at least learn from our techniques, hopefully. Right. So that was one of the major announcements from Microsoft this week.

Mary and Rassai, you want to talk a little bit about the other one we heard of? Which other one? We had a lot. I'm referring to the ASAN announcement. ASAN, right. Yeah, Marion, it's probably better to take ASAN than I am. All right.

So ASAN. Now it's supported in the MSVC compiler. And we've been working with Google on contributing some of the changes back to the ASAN runtime to make sure that the runtime supports beyond just some of the scenarios that are currently supported. Yes, Stefan.

Putting myself in the shoes of a developer who has not used this before, what is an ASAN? Oh, thank you. This is a great question. So it stands for address sanitizer and is

a technology that helps instrument your code to catch all memory allocations and detect memory overflows, overrides, reads and writes outside the boundary of an array. This technology has existed on Linux platforms

and I think initially originated on Apple platforms for a while now. And it has been available on Windows platforms through the Clang compiler for a very specific set of scenarios. I think Chromium was the only supported scenario, if you run ASan on chromium code base um obviously this is a very powerful technology there are equivalent technologies on

windows uh but this goes beyond what we have with the um some of the technologies like g flags or page heap and um we were really excited about the possibility of adding support for it in MSVC because there's still a lot of codebases out there that are only compiled with MSVC compiler. We started working on making sure that the ASAN runtime works across multiple scenarios and tested with some of internal codebases. We added support, again, to the MSVC compiler. And probably the most interesting part is the integration inside the Visual Studio debugger for ASAN.

When you build with ASAN and you debug your projects, you would get interrupted in the execution and get something similar to what an exception would look like in the Visual Studio UI. And all of the information about where the access happened, it's available either in the pop-up or in the output window. So, for example, building all your unit tests with ASAN and then rerunning them, there is very easy integration inside Visual Studio

to debug them, to get those crashes and fix them. Let's see. So Jim has a talk at CppCon, Jim Radigan, where he demos the new ASAN behavior. He talks a bit about how ASAN works behind the scenes with RMSVC compiler. And he also mentioned one of the services that we have in Azure that allows you to do fuzzing, which combined with ASAN,

it's a great recipe to validate your project. So you take your binaries, you upload them to the service MSRC. It stands for Microsoft. I have to think about that. But with security, I'll remember soon. There's going to be links in the talk that Jim has. Sorry about that. But basically, upload your binaries there.

They run for one, two, maybe five days with their inputs being fuzzed, and then you get the report back with all of the ASAN crashes that were identified. There's some merging going on. There's some smarts into making sure you don't get the same failure 20,000 times. You only get one report about it. And then with one click of a button, you can get that crash directly inside your Visual Studio as a crash dump with all of the context information from the Azure machine that ran the test, so you can fix it.

Sounds really powerful. So with ASIN, I haven't worked on the project myself, but I've heard a bit about what's going on there. My understanding is that we did work in the debugger and the compiler to light up those scenarios, like you said. But for the runtime support library, my understanding is that we're actually just building the code from the LVM repo as part of the VC libraries build. My colleague, Billy O'Neill, worked on integrating the ASAN build into VC tools.

Correct me if I'm wrong. No, that's absolutely correct. And the work we did is just a few patches to that runtime. Most of the work is incorporated from the open source project that it's the ASAN runtime. Most of the work is incorporated from the open source project that it's the ASAN runtime and that has been developed by Kostya from Google and it's been maintained. So I think it's great to be able to build

on the shoulders of the giants. Yeah, I was going to ask that. So my understanding is ASAN is a shared implementation, GCC and Clang. You're also sharing the same implementation? It's the same implementation, correct. Yeah, we just made it work with MSVC code bases. That's all.

And then for fuzzing, are you using the fuzzing sanitizer, like the same kind of API hook? Lib fuzzer. Yeah, lib fuzzer. Yeah, does it work the same way? F-sanitize, comma, fuzzer, or whatever? Not yet. So the MSRD service,

which is the Microsoft Security Risk Detection service, is using the fuzzing technology developed at Microsoft for the past 10, 15 years. It's a different one, but we're also looking at LipFuzzer. Some teams at Microsoft already experimented

with LipFuzzer on top of MSVC and they reported some success. So we are going to go talk with those teams and see what we can productize as part of the Visual Studio product. But we don't have like a fixed date yet when LipFuzzer is going to come. But it seems that it's technically feasible to go beyond just ASAN.

And the same is true for the other sanitizers as well, UBSAN, MSAN. And we're going to be looking at them and see how feasible it would be to have them work on the Windows platform. And when can we get our hands on the bits of Visual Studio with ASAN in them? So we just missed the window to have the bits available at CppCon. So the bits are going to be available in preview 2 of the Visual Studio 2019 version 16.4. So in one or two months from now, definitely before Christmas.

I wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high quality code, as well as the methodology of static code analysis. In their blog, you'll find many articles on programming, code security, checks of open source projects, and much more. For example, they've recently posted an article which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly use static code analysis.

Speaking of which, another recent article shows how to set up regular runs of the PVS Studio Static Code Analyzer on Travis CI. Links to these publications are in the show notes for this episode. Try PVS Studio. The tool will help you find bugs and potential vulnerabilities in the code of programs written in C, C++, C Sharp, and Java. Okay, and Sai, what was the other announcement you were referencing sure well one thing which we talked a little about last year was that we hit uh c++ 17 conformance and for our compiler and now with the charconf um edition we're now fully c++ 17 complete library and compiler. That includes the parallel STL.

Oh yes, we did ship the parallel STL. I did want to add one caveat. Our support for the C99 preprocessor that is part of C++17 is still guarded by an experimental flag, so there's a little asterisk there. But unless you're like Boost preprocessor,

that usually doesn't matter. Yeah, it is experiment. Now that we've achieved all of that, we've been working very hard on a lot of C++20 stuff. So we now have at least some support for all four

of the major features in C++20. Modules, coroutines, spaceship operator, and now we have feature-complete support for concepts. So the other three are partial, but concepts we have feature-complete support. It looks like you want to say something. Yeah, I thought you were still missing the ter syntax for concepts.

The ter syntax... Can you remember? Isn't that like abbreviated function templates or something? Yeah, like being able to put auto as a function. Yeah, my understanding, because I maintain our Excel spreadsheet internally that keeps track of our feature status, I believe we're tracking that

as a separate but related feature, because the concept constraint is that's the fundamental feature the abbreviated syntax that's just syntactic sugar and it's nice but it doesn't fundamentally let you write templates you couldn't write before it's just less typing i believe you're incorrect okay awesome but i could be wrong because i was just discussing this with someone last night i believe believe without the abbreviated syntax, it's impossible to constrain the return type of a function. Ah, interesting. Okay, possibly an asterisk there.

I have not yet used concepts myself. Neither have I, really. My colleague Casey Carter has been working on our concept-powered ranges. He's up to check-in 2 of 16 or something. So he would be able to answer definitively yes or no. I will take your word for it because that sounds exceedingly plausible. That sounds like what the core language would do.

That sounds like what the core language would do. And Jason, you should definitely try the concepts by using MSVC compiler and playing around with it. Yes. Thanks. Yeah, if people can try it out and submit any issues they have, that would be really wonderful. We're always looking for feedback and ways to improve all of these new features.

So please try all of those out and let us know how they go. Okay. Okay. So, Marion and Sai, I did go to your talk where you were going over VS 2019 updates and announcements, and we all already covered the main announcements you put in at the end of that with ASAN and open source STL. Were there any other highlights you wanted to mention for listeners to know about?

We had a few more announcements. Probably not the same caliber as open sourcing STL. But they're basically continuations of the work we've been doing inside Visual Studio inside Visual Studio Code for a while now so one of the announcements was Clang Tidy support integration inside Visual Studio and if you look at our track record

of integrating open source tools that C++ developers love inside the Visual Studio workflow it was like a natural progression we started with Google Test and Boost Test we added Clang Format a while ago plus developers love inside the Visual Studio workflow. It was like a natural progression. We started with Google Test and Boost Test. We added Clang Format a while ago. This year, we added Clang LLVM integration inside Visual Studio, so the installer will download a copy of Clang LLVM.

We configured both of the build systems, MSBuild and CMake, to very easily target Clang LLVM. And with this week's announcement, we're basically also enabling the static analysis part of Clang Tidy to run as a background service inside Visual Studio. So as you type code inside the editor and using Clang as a configuration, squiggles

are going to appear and you can interact with them and react to them dynamically. You get to pass the mic down, it seems. Does this also include support or is it working towards support for Clang-Tidy's automated refactorings like transform auto-putter into unique-putter and things like that?

So you'll see those squiggles showing up in the editor. There's no yet nice balloon popping up saying hey, do you want to fix it right here and there? That's something that we're investigating. I don't have yet a date of when that's going to be available, but that's certainly another

logical step forward with this technology. There's been some great talks about Clang Tidy at CppCon this year, and I think last year as well, they were very good ones. There's definitely lots of interest in this space, so we're looking forward to the feedback of people actually trying

the bits and letting us know how this Clang Tidy actually fits in their workflows inside Visual Studio. Yeah, one of the really cool things you can do with it now that we have the those squiggles integrated is if you have if you're you have a cross-platform application or library you're writing then you can have you know your native windows configuration and you can have a configuration on like wSL or a remote Linux server or something and if you just switch those configurations then suddenly you're like testing out two different

static analyzers and your squiggles will change automatically so you can be like try and get all your squiggles to go away in MSVC by using our static analysis and then you can just switch over and check out all of the Clang Tidy ones and try and fix those. So it really gives you really nice coverage with different tooling. I've yet to install WSL personally, and let's just say I'm developing a Qt GUI application. Is it just that easy? I can just run the Linux version and run the Windows version right there from Visual Studio? So you can't do GUI applications on WSL, but we have got really nice integration

for targeting WSL now. It used to be, like in VS 2017, you could spin up a SSH server on your WSL instance and do all of the remote Linux configuration and the IDE, but now

you just need to install WSL, make sure it has a few programs like rsync, zip, ssh installed. And then in the IDE, you just say, I want to target WSL. And it just does it. And it works. It literally is that easy. I've done it on stage, live, making a WSL configuration, targeting it. If you watch my CBPP talk on cross-platform development with our tools, you can see just how easy it is.

We also have a blog post as well you can check out. Well, and since I diverted you, though, from your cling-tidy integration comments, I'm curious, like, from your cling-tidy integration comments. I'm curious what checks are enabled by default, because personally, you all aren't responsible for this, but I've been a little frustrated lately. Our cling-tidy now has like 30 fuchsia-specific checks in there, and that doesn't affect 99.95% of developers.

They're things we don't care about. So I believe the default is star, which would include all of those checks but i've i found it very easy to create in the root of my code base like a dot clang tidy file and just start customizing that and the the squiggles and the editor in visual studio will respond immediately to those changes some projects already in gith come with those files, and it seems like to be the recommended pattern. Of course, you can configure it from Visual Studio UI as well to specify exactly what checks you have,

but probably it's easier to travel with the code base with that file. But yeah, the default is star. That's actually interesting. I hadn't realized until this moment that since we've added cling-tidy squiggles, it seems like if people open up STL header files,ang-tidy squiggles, it seems like if people open up STL header files, that they might

get squiggles within those. That are fuchsia-specific. Yeah, I don't even know what a fuchsia is, but that sounds ominous. It's like going plaid. Okay, and plaid is extremely bad. I wouldn't know it's very fast, I guess, at the very least if we're making baseballs references.

Yeah, so we try to be, we have extensive validation to make sure we're, you know, warning level four, analyze clean, that we're clang clean with all their, you know, their equivalent of W4. But we don't have any clang tidy coverage. So that's very interesting. We may need to add a.clang tidy to the root of our repo and figure out how to run the command line to get some validation there. You definitely should put a.clingtidy for what you expect as a word. So Fuchsia, I believe, if I have this right,

is like Google's latest kernel project for what might replace Android or something in the future. And so they're like highly specific checks. Yes, those are all words that don't mean anything to me. They don't affect you at all. And I did actually a C++ Weekly episode not that long ago that was Clang-Tidy checks to disable because they're starting to get in the way in some cases.

Okay. The one last thing I'll add about Clang-Tidy, when we did the integration, I mentioned that we default to Clang-Tidy if you have a Clang configuration. That is not the only configuration you can run clang tidy under um so it's also possible if you use your msvc compiler to enable our static analysis and clang tidy at the same time as a background process um so you have the flexibility of invoke clang tidy in which scenario you want

so since you just commented on your static analysis, when I go around teaching, I meet people who use Visual Studio regularly that still don't even realize that there's a static analyzer built in. If any one of you want to speak about that at all, go for it. That's sad.

I'll say that one of the reasons that, I mean, we did a lot of work to make sure that we make the static analysis a lot more accessible and the work we did to make it run as a background process that brings in squiggles in the editor is because of the challenges of enabling static analysis, any static

analysis tool on a large code base and for the first time and being overwhelmed with the long list of warnings that you get that can intimidate people and they turn to disable it back again the way the background analyzer works it only brings the squiggles into the active file you're editing okay so that you actually have a chance to to react while you're coding to those warnings and and being able to address them and we think that's a much better model than kind of the dogmatic answer that we had 10 years ago, like you should enable static analysis on all of your code bases and it should be a CI check-in criteria that you have zero warnings, which some teams do and it's great,

but it's also a costly investment to start. So if I'm remembering correctly, in many versions ago, wasn't static analysis restricted to like our equivalent of the enterprise edition? Yes. Yeah. And I believe now,

correct me if I'm wrong, stack analysis is available in the community edition. Yeah, static analysis is available in the community edition. I think we still have a concurrency check analyzer that is still part of the enterprise queue, but it's not the default concurrency one

that we've been talking about at conferences and the coroutines checks that we have. Those are available in the community edition as well. Which is important for open source projects to be able to validate because they're probably not going to have the enterprise edition. So that's really great great so are these squiggles enabled by default or do i need to go and check a box and say yes do static analysis too they are enabled by default yes well

okay since since we just talked about the clang clang tidy dot clang tidy is there like a dot msvc analyze file that i can use to set settings like that too? It's a bit different, obviously. We have the ability to configure to the level of a specific warning through a file called, well, any file that has the extension.ruleset. There is UI for that. There is a Visual Studio editor

that allows you to see the fullest of warnings and decide whether a specific warning should be treated as an error, should be a warning, or should be inhibited. And then it gets saved as an XML file. And that rule set file, you would have to wire it up in your build

to say, hey, please use this rule set file for my project. And the default is, we create a rule set file, which is the Microsoft recommended rules that you get by default, which I believe now includes some of the core checkers as well that maps to the core guidelines. But it's not a complete list. So if you want it all, all of the wordings that the MSVC static analysis supports, you would want to tweak with the rule

set file. Okay. And these rules, like the core checkers, those are distinct from the other static analysis warnings that have numbers in the 24,000 series that respect pragma warning push disable pop. Is that right? I hope that all of them support pragma push pop, but let me get back to you on that. But yeah, they're different. And again, all of the core checkers are the opinionated rules that tell you how you should modernize your code, not that it's something wrong with your code. Whereas our regular static analysis would be more into trying to find code errors

through the flow analysis that the static analysis would do. And now that you mentioned, I once run the core checkers against the STL just to see how many warnings we could fix. And I think they did have both numbers and names. So I think they do respect pragma warning. But I would have to check. Okay. Well, so we've only briefly touched upon the content of 14 different talks that your team

has given this week. But is there anything else specifically you wanted to highlight before we let you go? I'll mention one more thing that we presented at the end of the talk for Visual Studio, but it's valid for Visual Studio Code support as well. We have a private preview for a new project that we're working on. Let me set it up a bit. So we know that it's very hard for developers

to set up environments where they're successful working on. And during my talk, I asked people, how long does it take them to sit down for the first time on the machine and start enlisting, start setting up their project, their machine, and from that moment to the moment where they're happy with being able to build debug, but before they wrote any lines of code.

And it's surprising that the answer is not like five minutes or one hour. And the answers vary between a few hours to a day to a week. And one of the things we're trying to solve is through cloud environments, the ability to bootstrap an environment in under five minutes so that when you connect to it, you're ready to start coding. And obviously, this is a work in progress. We're trying to get more people signed up to the project to help us improve and enable this experience further. But the main idea is, and I demoed it in my talk, you point to a GitHub repo.

The cloud environment tool analyzes that GitHub repo and decides based on the content of it, whether it has C++ or it has Python in it, to install a specific set of components that you need in that environment, including a Visual Studio copy that you can then, from your local machine, remotely connect to. And this is not a remote connection like through, I don't know, SSH or some other visual channel. Visual Studio knows that the local copy of Visual Studio knows how to chat with the

Visual Studio copy that gets installed on the remote environment. And you're ready to start coding immediately. All of the builds happen on that remote machine, so none of the CPU is being spent from your laptop. And when you're traveling or you can have access to those

cloud environments very easily. And you can have as many as you want and they can be frozen if you're not actively working on them but they're there all the time and they're ready to be revitalized if you need them to. And we find that this kind of solves

the problem of the hardware limitations that we have. We have as many environments as we can but if we don't have the machines to set them up then we probably wouldn't keep a branch with a long-term service uh that we still need to support from time to time available and then it's kind of like a hassle that we need to go back and maybe service uh some old branch like that doesn't have to be a big problem and we're working on fixing that

yeah very cool um so the idea is you you know, if I have, like, some old version of a C++ compiler, you know, I wouldn't have to keep that installed. I could get that through the cloud environment and things like that. Yeah, and the idea would be that you can, you don't have to worry about the steps of configuration. Someone in the team can

obviously customize an environment, but you would be able to give a great experience to someone just walking in for the first day of their job. And you just point them to this cloud environment and they're ready to go rather than giving them 20 pages instructions and letting them struggle for a week.

That's kind of the big value add. And I think the key is in how we enable customizations of these environments because obviously every project is different. And that's the thing that we're looking for people to join the program and give us the feedback of the customization points that we need to enable. And we hope this is going to really move the needle in terms of team productivity. If you want to get in on this preview, how would you go about doing that?

So visit our blog. We're going to have get in on this preview, how would you go about doing that? So visit our blog. We're going to have some blogs on this. There is on Visual Studio blog, not the Visual C++ blog, but on Visual Studio blog, a link to sign up on one of the blog posts. Maybe I can send it to you, Rob, on the link and you can put it in the footnotes of this interview. Okay. Well, thank you all for coming on the show today and sharing some of this content. I definitely encourage listeners to see some of these talks

when they come up on YouTube in a couple weeks. Thank you for having us. Thank you. And our STL repo is github.com slash Microsoft slash STL. Awesome. Yeah, thanks very much. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast.

Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter You can also follow me at RobWIrving and Jason at Lefticus on Twitter We'd also like to thank all our Patrons

who help support the show through Patreon If you'd like to support us on Patreon you can do so at patreon.com slash cppcast And of course you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.