CppCast - Visual C++ Conformance

Episode Date: June 15, 2016

Rob and Jason are joined by Andrew Pardoe to discuss Visual C++ conformance progress as well as experimental features like Modules. Andrew started working at Microsoft in 2002. He worked for the C++ team for exactly five years, first on testing the Itanium optimizer and then on the Phoenix compiler platform. He left in 2007 to become a PM on the CLR team (the C# runtime). Andrew left that job about two years ago and through the magic of corporate reorgs ended up as the C++ compiler PM. In his role at Microsoft Andrew pays attention to pretty much everything without a GUI: the compiler front end/parser, code analysis, and a little bit to the optimizer. He also owns the tools acquisition story—such as the VC++ Build Tools SKU and updating to latest daily drops through NuGet—and Clang/C2. The Clang/C2 work is what ties Andrew into the Islandwood team, and the code analysis work focuses mostly on the C++ Core Guidelines checkers. News How the Commodore 64 Memory Map Worked FunctionalPlus, a C++ library, now has a (i.a. type based) search website for its over 300 pure and free functions Standardese documentation generator version 0.1 Awesome C++: Curated list of awesome C/C++ frameworks, libraries and resources Andrew Pardoe @apardoe Links C++ Core Guidelines Checkers: Preview of the Lifetime Safety checker Expression SFINAE improvements in VS 2015 Update 3 Standards version switches in the compiler Sponsor Incredibuild

This episode of CppCast is sponsored by Incredibuild. You won't believe how fast your build can run until you download your free developer version at incredibuild.com slash cppoffer or just click the link on our website. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket now during early bird registration until July 1st. Episode 60 of CppCast with guest Andrew Pardot recorded June 14th, 2016. In this episode, we talk about some awesome C++ libraries. Then we talk to Andrew Pardot from the Visual C++ team. Andrew talks to us about Visual C++ conformance and some experimental features. Welcome to episode 60 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner.

Jason, how are you doing today? All right, Rob, how about you? Doing pretty good. I know you said you didn't want to, but do you want to share the video you just posted on Hacker News the other day? It was getting pretty popular. Sure. Well, so I've mentioned I've been doing C++ Weekly for a while now, and I just decided I wanted to do some videos that were just a little bit more like fun and not on a weekly rigid schedule. So I've done a couple of what I'm calling the Retro Programmer. And the most recent one that I just published

is tracing some logic circuits on the Commodore 64 to discuss how memory mapping works with a video chip. And it spent about 15 hours on the front page of Hacker News yesterday, which was pretty cool. I was pretty happy with that. And as you said, that's extremely impressive with all the news coming out at WWDC right now. Yeah you know if i had realized it was wwdc day i probably would have waited a day

to put it up there but it resulted in like something like 3500 views so yeah pretty cool very cool okay well at the top very episode i'd like to read a piece of feedback um we got a lot of great responses from last week's episode with Jonathan Mueller. And one of the comments we got on the website was some of the concepts he used in building his library reminded me of one of Andre Alexandrescu's talks. So having a young programmer being compared to Andre Alexandrescu in any way is pretty impressive feedback, I think. Yeah, you know, that's exactly the kind of things that I was accomplishing

before I went into college, you know. Popular open source libraries. This guy's really setting a high bar for 18-year-olds out there who haven't even gone to school yet. Anyway, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com.

And don't forget to leave us reviews on iTunes. Just one quick note. Last week, I know we started giving out licenses to JetBrains. We switched sponsors this week for the next few episodes. We're now being sponsored by Incredibuild, which is great. We really appreciate their support. But we're still working things out with whether or not we can give away some free licenses. So hopefully we'll get that sorted out for next week. Joining us this week is Andrew Pardot.

Andrew started working at Microsoft in 2002. He worked for the C++ team for exactly five years, first on testing the Itanium Optimizer and then on the Phoenix Compiler platform. He left in 07 to become a PM on the CLR team, which is a C-sharp runtime. Andrew then left that job about two years ago and through the magic of corporate reorgs ended up as the C++ compiler PM. In his role at Microsoft, Andrew pays attention to pretty much everything without a GUI, the compiler front end and parser, code analysis, and a little bit of the optimizer. He also owns the tools acquisition story, such as the VC++ build tool SKU, and updating the latest daily drops through NuGet and Clang C2.

The Clang C2 work is what ties Andrew into the Islandwood team, and the code analysis work focuses mostly on the C++ core guidelines checkers. Andrew, welcome to the show. Thank you. Glad to be here. Andrew, I see at least two things in this bio that kind of look like Microsoft internal code names. What is the Phoenix Compiler Platform, and what is Islandwood? Okay, so Islandwood is the easy one. That's not actually internal. That's out there on GitHub.

Microsoft, a few years ago, announced bridges to Windows that they were going to provide ways that you can bring Windows desktop apps forward to Windows Store. And Islandwood is a project that lets you bring iOS apps forward to Windows Store. So you can actually take an iOS app, reuse all of your own logic and Objective-C, tie it into our UI framework, and basically port an iOS app from iOS over to be a Windows Store app. This one I was actually familiar with. I went to Build two years ago, and I think it was one of that game, really popular game, Candy Crush. Candy Crush, yeah. Used Islandwood to get onto Windows. Yeah. one of that game really popular game candy crush yeah i think they used islandwood before we bought

islandwood but i'm not real sure how that works what i know is the phoenix compiler so the phoenix compiler was a few years ago um many years ago we decided to rewrite our optimizer into a platform for code gen, code analysis, optimization. It was an incredibly ambitious project. It was similar to what LLVM became. It was concurrent or predating LLVM. I won't get into details there, but it was an incredibly ambitious project, and it kind of crumbled under its own weight. But it was a great compiler. Lots of fun. So it doesn't exist anymore, in other words.

It does not exist anymore. There were educational releases out there, so the source may be floating around the web I'm not sure but with many things at Microsoft we end up having a project sometimes putting it out there sometimes not when it gets cancelled it actually comes back in another form the magic of corporate reorgs that I was talking about there was a project called Midori that was an operating system written in C-sharp, almost completely in C-sharp. Incredibly fast, really great technology. Getting it to market was a bit of a problem. Well, when Midori was broken up, it became a couple of groups that are still pushing forward what Midori was doing, but in ways that can be faster to the market than what Midori was.

A lot of the work that we're doing with the core guidelines checkers is influenced by the Midori work. And this morning, David Tarditi, or yesterday, I think, announced checked C. And this is just a set of additions to the C language that allow you to avoid buffer overruns and dangling pointers, etc. David is a researcher from the Midori team. Now that he's in MSR, he's applying what we learned in Midori to something that can go to market more quickly. Okay. Okay. Well, Andrew, we've got aori to something that can go to market more quickly. Okay. Okay, well, Andrew, we got a couple news items to go through. Feel free to comment on any of these, and then we'll start talking to you about Visual C++ conformance and more.

So this first one, Jason, have we talked about this library before, Functional Plus? I'm pretty sure we haven't. Okay, well, Functional Plus is a library of pure functions, and it's now very easily searchable, right? Yeah, and I feel like a lot of C++ developers have a functional leaning these days. And to know that there's this library of 300 functional functions. Yeah, 300 pure and free functions and a very, very fast search page where you can type in Haskell-style type signatures

to look for what you're looking for, or you can just do name-based searching. But it's a very easy library to navigate now with this new search page. Yeah, it's pretty cool looking. Yeah, maybe we should see if we can get the developer of this library on the show sometime. Okay. Yeah.

Another article. We were just talking to Jonathan Mueller last week. We touched on his standard ease library a little bit, and he just released this blog post that he is putting it out as a 0.1 library and he talks about some of the improvements he made since his initial post about it improving his parsing algorithms what else is in here Jason yeah I was actually the reddit discussion about it some people point out to him some things like because he mentioned on the air with us that he had to use boost wave because libclang couldn't

give him all the information needed and people on the reddit discussion are like dude you really need to submit bug reports to libclang because you should be able to get this stuff out of libclang so i just thought that was cool too that hopefully you know maybe that'll create a good feedback loop and they'll get some better responses from Libclang, too. Yeah, it'd be great. It's always great to see Libclang improve. As soon as you guys pointed me to this, I immediately thought of Donald Knuth when he was writing The Art of C++, The Art of Programming. Sorry for my bias there. The Art of Programming, that he paused for a bit to write

his tech language so that he could get the typesetting that he wanted. And this is kind of what Jonathan is doing, right? Like he didn't really want to write a standard ease generator, but he wasn't happy with what Doxygen was doing. So fine, he'll write his own. I think it's great. That is a great way of looking at that. Yeah. Okay. And then this last thing we have is Awesome C++, which is a curated list of Awesome C++ frameworks, libraries, resources, and shiny things. And this is also very well organized and very searchable. So if you need a certain type type of library you need something for networking need something for logging or testing this is a good place to go to see what's available

and uh i guess there's not much more to say about this i'm not sure how to go about adding new oh actually there's a button right here so if you so i'm looking at his testing libraries and only has two so he doesn't have catcher of the other ones we've talked about before. But there's a button right here to add a new testing library. You just paste in a GitHub link, and then he'll add it to his list. That's pretty cool. Catch totally needs to be on there if it's not. Yeah, I might add it right now.

Okay. okay so andrew um just a week ago you posted a whole bunch of new blog posts on the visual c++ blog maybe you could start there and talking about visual c++ conformance can you tell us about some of the most recent changes that are coming in for c++ 11 and 14? Sure. So as you may know, MSVC has been kind of the standards bearer for not conforming to the standards for quite a long while. You make it sound like it was intentional. It was not intentional, but it was definitely not a great situation to be in.

For a long time, we focused on internal code as well as our external customers, but I think maybe we needed to shift the dial a little bit more towards what our external customers needed. And frankly, you'd be shocked out there in the industry how many people are writing C++98 or even with classes or sorry c++ 98 or even c with classes it's um the state of programming is not quite where i'd like it to be where everybody's writing c++ 14 and eagerly adopting features as the committee discusses them um but in the end of the last cycle so we're in the dev 14 cycle vs 2015 in the end of the previous cycle we decided we're really going to focus on making our compiler completely conformant we had a huge problem in that our parser was not a recursive descent

parser our parser used a token stream so it would basically read the tokens, lay them out in a flat stream, and then you lower the code as you read your token stream. For things like Expressions FinA, things like two-phase name lookup, it made it really, really hard to go back into the token stream and see what you might be looking for. If you have something that generates syntax trees, then it's easier to kind of pop up your tree and say, okay, I've got this alternative, this alternative, but reparsing a token stream, just, it really just takes too long. And I'm told that, you know, supporting two phase name lookup is just impossible without a new parser.

So we started on a new parser. We started on bug fixes at the beginning of the Dev14 cycle. We've done a lot with Expressions FinA and constexpr and just general conformance. But we started a new parser sometime late last year, I think. There's a great blog post by a dev on our team that talks about rejuvenating the Microsoft C++ compiler. And that goes into detail about how we're replacing the parser. As we do that, a lot of the conformance issues that we have just fall out from there.

So we are hoping to get completely conformant with C++ 98, 11, 14. And to do that, I'd like to say by the end of the year, but I know a dev lead who would probably be hunting for my scalp if I said that on the air. So right now, we don't have two-phase name lookup. Our expression Sphine has some issues. Our generalized constexpr has some issues. And then nstmi for aggregates has issues. And then the occasional bug here or there.

But right now, we're actually pretty close. So we're within spit and distance. So if I download Visual Studio 2015 update 3, am I using some of the results of that new parser today? You definitely are. Yeah. Okay. The compiler that we're working on today has a few weeks leg into what we ship in the Visual Studio updates. And so you'll definitely see those improvements as you go.

As well as a number of C++ 17 features that we put in. Variable templates, for example. All of those features are in the compilers that we ship. We have started to, and I guess this is another thing you wanted to discuss, we've started to guard feature sets through standard switches, standard version switches. This is something that GCC, as someone reminded me on my blog post, GCC has been doing for eight years. So, yes, thank you.

We are catching up. We know we're catching up. Clang has been doing for a while. But we have a std C++ 14, which is the default switch. And then we have a std C++ latest that will enable the c++ draft version features that we have implemented and those are the ones that were not shipped in update 2 unfortunately there are some that we shipped in update 2 such as variable templates that we're not going to go ahead and put them under a switch now because that would be a breaking change and microsoft is microsoft because we keep our we avoid breaking changes we

keep our developers code working like that's that's win 32 is what made this company rich right so we can't break people and so we have some c++ 17 features that are unfortunately under the 14 switch but then we've got a few features like there's some rule changes for auto with braced init lists, removing try graphs, attributes for namespaces, enumerators, there's a list of five or six on the blog post that are under the C++ latest switch right now. So I'm curious, you mentioned a moment ago that you want to have full conformance with C++ 98, 11, 14, moving forward, is the plan to go back and add switches saying I want C++ 98 strictness,

C++ 11 strict? The plan is not. If there is a sufficient demand from our developer audience, then we may do that, but the plan is not to do that. We really think it's in everybody's best interest to move your code forward to be C++14 conformant. If you are using code that is strictly C++98 because, say, you've got a product you haven't touched for five years you probably don't want to touch your code anyway except for bug fixes and in that case a switch

isn't going to help you right so while we started later than gcc and clang with the switches so we don't have the 11 switch i don't think it's something we need to go back and fix up okay um going back to expression sfine a little bit so if i recall are were there promises made that that would be fixed with a vs 2015 update i know you said you're hoping to get it in by the end of the year but is it going to be a 2015 update so uh promises we try never to make promises. You make promises and then you have big, huge co-incorporated who has a support contract, comes back and says, you promised. Without a lawyer, I will not make any promises. We would like to get it in for 2015, but 2015 is kind of closing out we usually do four or five updates to a product and we've already announced visual studio 15 i think we're calling it the visual

studio next so it's unlikely that we'll end up with all the expressions finna improvements in the 15 cycle but the compiler pretty much works independently of Visual Studio. They just kind of grab our latest and put it in with, of course, gated by what we can get into the IDE for IntelliSense and support, tag browsing support like that. So we will keep marching on. As soon as we get our parser work finished we should be able to get expressions finna completely supported so hopefully by christmas but like i said death threats from developer leads

and your bio you mentioned that you uh you deal with the latest daily drops of the Clang and C2 compilers and stuff. So what I'm wondering is, is it possible today to get the latest and greatest compiler, even if it has not been shipped in an update? Yes. So not with Clang. We're still working on getting Clang into that. But we did something some time ago that, sorry, I'm always bad with the past. It's the history part of it that gets me. But we did something maybe February-ish there.

We started putting drops of the C++ compiler tool set on NuGet. And this is kind of a nifty trick that one of our devs figured out, that he could rewrite the project files and basically slam an entire tool set on top of your project. And now you're using whatever you downloaded from NuGet. And then you want to go back to your regular project, you just uninstall that NuGet package. And it's a big honking NuGet package. So one, we can't host it on the NuGet server. And two, it does take a minute to install.

But it's really convenient. We've got this one guy who sent in a bug report that said, hey, my code broke on this version of the NuGet package. And then I went back to, and it turns out that it worked on that one. So sometime between this date and this date, you introduced a bug. Wow. Thank you. That's great. And so a couple of months ago, we actually updated it. So now the daily drops are being put on the NuGet server. And there's a blog post about this on the VC blog.

The daily drops are kind of misleading. Microsoft, the VC team has an official drop server where we produce what we call signed builds that you can't just change the binary because they get invalid signatures and such. The official drop server gets an update from the parser side of the world every 10 days, roughly, and one from the optimizer linker side of the world every 10 days, roughly. So the compiler tool set that you get on, and then the libraries go with the parser,

the compiler tool set that you get off of NuGet should update about every five days. And it is the case that the tools you get on NuGet are usually newer than the ones that people in Microsoft are using outside of the VC team. Oh, wow. That's pretty cool. Yeah, you can hit bugs before Windows does, too. Or bug fixes, right? Conformance improvements. So, I'm going to go out on a limb here, but any chance we'll see... Microsoft's been open sourcing a lot of stuff

lately. We have. Any chance that we'll see the compiler open sourced, and then we can just build and help you guys go to a commit, tell you this commit is what broke my code. That would be lovely. Um, I think the biggest challenge that corporations with old code bases face in open sourcing their code is that the code is embarrassing. I E released some code recently.

I don't remember what the piece of code they released was, but the Reddit threads were like, wow, this code is awful. Did they write their own smart pointers? What were these people thinking? And then somebody comes back and he's like, yeah, IE. It's like they existed before smart pointers. It's actually not a bad smart pointer. If you didn't have a smart pointer, why didn't they go back and fix it?

Well, because you have to work on new things. Our compiler is probably not the prettiest code out there. That isn't something that would prevent us from open sourcing it, though. We've definitely considered the benefits and drawbacks. Okay. It's not beyond the range of possibility. Not by any means. And actually inside of Microsoft now,

it is usually up to, I'm sure it's more than just, but it's usually up to a team. At least it feels like that as to whether or not you do a project closed source or open source. Like this really is a new rodeo here. Wow. Oh, wow. That's pretty cool.

Let's talk a little bit about new features like modules. You've been shipping an experimental version of that for a few months ago, for a few months now, right? Yeah. Yeah, we actually, the experimental switch is also a nice thing that we can actually put in large, not completely stable when it first shipped features into the compiler. And because it's experimental, not have to worry about breaking people. Like I said, we're always concerned about breaking changes. Modules are great. We've been using

them internally with a couple of teams. I don't, yeah, I'm not going to name names yet, but go to CppCon and you'll find out who I think. The real benefit from modules, at least the C++ modules that Gabriel Dos Reis is putting into TS, is componentization that when you define a module interface, you say, hey, this piece of code has these functions. Like these names, these variables, these functions should be available to code that consumes your code. And this is completely different from a header file that says, hey, here's a pile of code that I want the compiler to include completely

in this other pile of code. And, you know, I could have the lyrics to Mary completely in this other pile of code. And, you know, I could have the lyrics to Mary Had a Little Lamb sitting in there, and it's going to come in. It doesn't matter where I've got internal functions that are only meant for my own housekeeping as I built the library or whether I've got things I actually want you to call. You get it. And it's different from visibility, you know, like private and public and protected functions. The other thing that Heather Files bring in is the macros.

We have teams that are just dying under macros. There's a lot of macros out there that made a ton of sense years ago. When C++ didn't have the abstractions that it has in 14, people would write things, macros that would do memory management and class cleanup and what have you. And these macros, once you include something that includes something that includes something, I can't tell you how many times Windows.h gets included when you build a particular project in Windows. It's insane you know then you end up with like null being defined and it's it's just crazy min and max are fantastic ones my major pet peeve right there with visual studio min and max god so please it's not that we want a world without macros macros are

an important part of the language but i don't want to show my macros to people who are consuming my library. If I do need to expose some macros with my library, fine. I can stick them in a header file that's just a few macros. And that way you can look at this file. You could be like, okay, this is what I'm getting. This is the state that's coming in with this particular module. And then, of course, the one that you always hear about is build scalability. I think that really just falls out from better componentization. Once you know what your code is doing, you don't have to rebuild your modules.

You don't have to rebuild a module. A consumer doesn't have to rebuild a module as opposed to, like I said, you're including Windows.h n times. You have to recompile that, reparse that every time. You'll end up with some significant scalability benefits, just faster build speeds. And the last big benefit from modules that we haven't seen yet, but we will see, is when you're specifying your interface in a nice binary format that people can read, we're going to end up seeing build tools

in a way that we've never seen with C++ before. Right now, if you want to write a tool that works with C++, you have to write a tool that understands C++, right? That's pretty much a tautology. The only thing that understands C++ is a C++ parser. And so you pretty much have to write a C++ compiler to write a tool that works with C++. When I was on the.NET team, I wrote a bunch of little tools that worked with.NET because you've got all of this rich metadata sitting there in a database, which of course has huge drawbacks, but huge benefits. I can work with.NET objects without actually understanding the C-sharp language.

And I don't think we want to go completely to the place where Java or.NET is or any language that carries the weight of its metadata with it. But having your interfaces clearly specified will make tools development far more easy, or easier, as the kids say these days um since you brought up the the macros uh with modules that's kind of the main argument going on in the specifications team over how module is going to look right so richard smith had a paper in um jacksonville the spring++, the meeting in Jacksonville, that brought up a number of concerns with the TS. One of the concerns was the ability

to export macros. I would say that's probably the major sticking point between the TS and the paper that was brought up. This is one of the things I love about the TS, the technical specification process in C++. You know, Gabriel can write down what he thinks modules should be. Like, it's basically the paper that he's had and that he's discussed for many C++ standards meetings, but he gets it down into a technical specification. And then, you know, Richard and company, Richard Smith from Google and other folks who have concerns about the technical specification can go in and change something that's written down. It makes the argument concrete. And we

can end up with a better language. And we also, with the technical specification, having it written down means that other vendors can implement it, and we can get some real-world experience more than just inside of Microsoft. So, yeah, I like it. What kind of feedback have you been getting from modules, both internal and external? Externally, a lot of people love the design.

People love the... The biggest benefit, actually, internally and externally we've seen is that people just love having your interfaces clearly specified. Right. The corollary to that is that it's not like Clang modules where you can just flip a switch, not exactly so easy, but you can just flip a switch and all of your existing code gets modularized for you. There is some work in defining an interface for your code. So the feedback has been pretty positive, but I wouldn't advocate turning around and using modules for...

MFC was something that was brought up. MFC is defined on macros. There's a ton of macros that get exported. The same with the ATL library. I would never advocate converting ATL and MFC to modules. Those are from a different era. They'll still be usable. I could see somebody wanting to wrap them in a module or they don't really know what

the benefit would be to that. It's really for code that is cleanly componentized. You want to have cleanly componentized. I want to interrupt this discussion for just a moment to bring you a word from our sponsors. Incredibuild dramatically reduces compilation and development times for both small and big companies like EA, Microsoft Game Studios and NVIDIA. Incredibuild's unique process virtualization technology will transform your computer network into a virtual supercomputer and let each workstation use hundreds of idle cores across the network. Use IncrediBuild to accelerate much more than just C++ compilations. Speed up your unit tests, run more development cycles, and scale your development to the cloud to unleash unreal speeds. Join more than 100,000 users to save hundreds of monthly man-hours

using existing hardware. Download your free developer version at incredibuild.com slash cppoffer or just click the link on our website. So what is the state of coroutines, which also you guys are taking the lead on? Yeah, coroutines, we decided that's a Gornishan's proposal. We voted in Jacksonville with Microsoft's recommendation, actually, or the people from Microsoft's recommendation, to put it into a technical specification, although it had already been tentatively, at least by evolution, approved to go into the C++ standard because there are concerns. The concern right now is mostly around stackless versus stackful coroutines. In a stackless coroutine, there's a tiny amount of state preserved on the stack. Stackful ones are more like fibers were in Windows that require that you save off registers and state for each cover team. There was some other concern about suspension, whether the collar suspends or the cover team

suspend up or suspend down, and whether the suspension is viral to any extent. But I think that we're getting to a good point with co-routines. I'm excited to see them in a TS. The two proposals are not terribly far off, but, or at least the TS and the other papers that have been heard on cooutines. They're not terribly far off from each other, but the concerns that are out there, such as Stackless versus Stackful, they're really central to the design. So it'll be interesting to see this one hammered out. One of the concerns that I've seen come up with for why concepts aren't in C++17 yet is only one compiler implements them and we haven't had enough time with concepts

to know if they're the right choice. Do you know, so taking that backwards to the coroutines and modules that we just discussed, are other compilers starting to support these things so that we can get more experience with them? That is the big problem of technical specifications is you write them down, like I said, so that everybody can implement them.

But then what you really need is for every vendor, at least like you guys called it, the big three, GCC, Clang, and MSVC, actually need to implement the technical specifications so that you can try it out. Right. It's hard. Like, I wouldn't want to go shaming anyone saying,

hey, you should be implementing modules the way the TS says, and you need to do it by this time so that we can get some experience. It's far better, I think, to lead by example on this. One of our most recent hires on the C++ team is Casey Carter, who is the implementer of RangeV3. And we've also been using RangeV3 as one of the two test cases for Expressions FinA. We have more than two, but those are the two that we've talked about at this point. We recently got Boost to compile due to Expressions FinA fixes on our end.

We got Boost to compile without changes, and Beeman Dawes sent a mail out to the Boost developers list saying, hey, you know, Microsoft is no longer special case code. A bit longer of a mail, but that was a great I really appreciate his team's help in getting to that point. Ranges, we still have a pile of bugs on range V3. But, you know, we are still working on the expression Sphine, and we've hired Casey Carter to make sure that we can implement range V3

in our compiler. Unfortunately, two ways, one that works with our broken non-conformant compiler and one that works with our conformant compiler. And so we're really trying to get out there and support the TS and make sure that we can lead by example, that supporting other people's TSs makes sense. I think if when concepts gets to the point of the standard, if it should go into a TS, then I would push to do that as well. In your bio, you mentioned the C++ core guidelines work and how you're involved with code analysis. What's kind of the latest with the core guidelines checkers so uh we have been working on the lifetimes problem um so the c++ core guidelines they define a so the guidelines themselves are

set up as a set of guidelines about how to write good C++. In them, there are some profiles that are called safety profiles, or at least we call them internally. And there are three safety profiles that we started with, which are bounds safety, type safety, and lifetime safety. We picked these three because if you compare it to C-sharp or Java or any of the type safe languages, those are the three things that these languages try to guarantee. Although type safety is not completely safe in any of these languages. The bound safety and the type safety checkers have been done for a while.

They were really the easy case. The lifetime safety is a tough nut to crack. I mean, it's been an ongoing research problem since people started thinking of how do we make sure we don't have dangling iterators or dangling pointers. We're making improvements. Something a lot of people don't realize is that as the compiler's new parser gets more accurate,

the code analysis that we get out of the engines that drive the CPP core checkers, in fact, all of our code analysis also gets more accurate. And so a lot of the challenge is not just that the lifetime's work is so hard, and frankly, we're not even finished specifying it yet, but also that the compiler that we're working with is not completely conformant and doesn't offer the best platform that you could want for code analysis. Are Microsoft and the Clang team collaborating in any way on the checkers? We just recently read about how Clang Tidy is starting to implement some of these. Yeah, Clang Tidy has actually been implementing these.

That's one of the beautiful things about Clang. Manuel Klimek at CppCon last year, the C++ conference. This was in September. Bjarne announced the core guidelines at the C++ conference in his keynote. And we had some checkers ready to demo at that point. Manuel Klimek from Google sat down and gave a lightning talk on Friday where he implemented a core guideline checker in Clang Tidy, which was fantastic. So he had been out for four or five days, and there he is coding it up. That's the open source world.

Clang-Tidy has been really good about keeping the guidelines checkers up to date. And they've even added, I think, a couple that we don't include. We have some checkers that aren't specified in the profiles as well, like const correctness. I don't think that they've tried for any of the lifetime rules yet, although I haven't looked at them lately. We're not collaborating in these except for the fact that the CPU++ core guidelines are across industry. We've been getting a lot of participation from a number of companies, like Titus Winters from Google has been fantastic in submitting PRs and raising issues and causing long discussions. But the guidelines are out there,

and anyone can implement the checks for the profiles. We have been collaborating with the Clang guys a ton on the Clang C2 work. So one of the challenges that we have, as well as the LLVM team, is how do you make Clang work well in the Microsoft ecosystem? One of the keys to that is can Clang emit Microsoft PDBs, right? Because our PDBs have never really been specified. You can see discussions on the Clang developer lists about, well, I sat down and tried to debug this PDdb and i discovered that these are these different streams and i've got a hundred kinds of different streams in this one and i know what a handful of these streams are but i don't know what the rest are where do i find this documentation answer is you

don't so we have been working with them on two fronts. One, we've got a GitHub repo up there that really just has source code from the compiler optimizer and the linker. It's called Microsoft PDB or some such. And this one is somebody at, it's usually somebody at Google who has asked us, although we've been asked by a couple of other folks.

I don't understand how this works. You know, I know this much, but I can't get this last bit. Can you help me? We figure out what source file it is. We make sure that we can open source that source file and we just throw it on the repo. And then we can answer questions and we can both talk about the code. So it's an odd repo in that there's really not anything buildable in that repo. You might be able to build cvdump,

which is a tool that we distribute with our compiler, because all the source for that is up there. But I think even that one was the last file that we put up there, was cvdump required an internal header that defined a hashing function. And so I went and grabbed the hashing function and stuck it in a source file and uploaded that source file so that the guy could build it. So one is opening up the pieces. We're not ready to open up the optimizer.

We're not ready to open up the linker today. No promises about tomorrow. But for right now, when people need to see the code, definitely stick it out there. Let them see the code. The other thing we're doing, one of our devs, Dave Bartolomeo, has been working on the Clang C2 for quite a while. He's been working on getting the code view format pushed into Clang. We made the changes internally. It's the biggest set of changes we made for Clang C2. It enables Clang to emit the code view format which then gets munched into PDBs by the back-end, the optimizer and the linker. We have all the code view work

done. We sat down and talked with a bunch of Clang maintainers at Google. They were great. We had the Google guys, because everybody's down in the valley together, we had them talk to a bunch of Clang people at Apple. Google outlined the benefits of bringing in the official code view and you know they're just they're working through this for us. But we really hope to get the code view information in the mainline Clang trunk soon. So Clang team has been great.

One of the nice things about the new Microsoft is we love everybody. And increasingly, they love us. So I can tell you, i've been really happy working with clang folks both in the standards committee and in the work that we do um yeah they're a bunch of great guys that's cool not to diss gcc because jason's awesome too he's the only gcc developer i have worked with i've got one uh final question about the core guidelines they're huge, right? they are huge

so what is your ultimate goal for the core guidelines checkers? how much of this do you plan to implement? so a large number of the core guidelines will never be machine enforceable so I think the core guidelines will never be machine enforceable. So I think the core guidelines have two roles. One, every company and sometimes every team, sometimes in some teams inside of Microsoft, I won't name which, every dev lead has their own set of coding standards.

And, you know, if you've got five coding standards, you have no coding standards. And you know, if you've got five coding standards, you have no coding standards. And so Herb Sutter and Andre Alexandrescu worked on a book a few years ago, they published a book that was about how to write better C++. The name is escaping my mind right now. And we were restarting that effort inside of Microsoft to try to get just a single coding standard for C++ inside of Microsoft. When Bjarne got word of it, because, you know, her and Bjarne chat all the time, Bjarne's like, hey, I've been writing up a set of guidelines myself,

and so we swapped over to what Bjarne was doing and kind of stuck all our wood into that fire. It really is. Let's have something out there that anybody can suggest issues to, anybody can write pieces to. Let's end up having a guideline that works for C++ that's up to date about this is the way you should write modern idiomatic C++. And, you know, if you happen to be, I won't pick on Google, if you happen to be in the Microsoft kernel team, because the same is true for parts of Chrome, if you happen to be on the Microsoft kernel team

and you believe that exceptions are unacceptable for your code for whatever reason, fine, fork it, amend the part on exceptions. The rest of it is still valid. You can make your own local guideline, and then you can diff it to what's out there. So I think that's a great effort. Kate Gregory is going to be teaching a class on that before CppCon this year. I think it should really be a good way to introduce people to, look, this is how you should write C++. And I love that it's not owned by any individual company. When we rebooted this to work with Bjarne's source document as opposed to the ones we were using, I think it was the best move we made. The profiles, the aim for the profiles is that you can know where your code is suspect. We have these suppress attributes, GSL suppress that allow you to

suppress any of the warnings that the profile checkers may give you. And the idea there is, if you run, say, the type safety checker over your entire code base, then you know that your code will not commit type violations, right? Same with bounds, eventually same with lifetime. But this is C++. You use C++ because you need to do type violations in some places. You need to do bonds. And frankly, we have people who are writing actual machines, machine code. It just doesn't stop. You go all the way down with C++.

This isn't Lisp. So having the suppress attribute then gives you this situation where you can say, hey, this is the part of the code where I'm doing something suspect. Now when it's time for code review, you know what code to pay attention to. You look for the suppress attribute. You can make your simple code simple. You can have the machine check it for you. You can pay attention to the stuff that matters. You know, you pay attention to your tricky inner loops and your, your lock free containers and your bank, all the wizardry that you do with all of your template metaprogramming, fine, go crazy, but spend your time code reviewing

that instead of code reviewing the parts that just grab data packets off the network and munch them in some boring fashion. So we're really hoping that through automated enforcement, people can write better C++ code and be more confident about their C++ code internally and externally. For listeners who were curious about that book you mentioned, I believe it's C++ Coding Standards, 101 Rules, Guidelines, and Best Practices. That is the book. Thank you much. I own it, but I could not remember it when you mentioned it. I own it, but I lost every memory I had when I started this discussion.

Okay, I think that's all the questions I have. Jason, is there anything else you wanted to ask? I believe that's everything I have also. Okay, Andrew, it's been great having you on the show thank you it's been great being here to define more information I guess the Visual C++ blog the Visual C++ blog is fantastic

we actually have an external email address visualcpp at Microsoft that I think there's only a handful of people on it but I am on that my email address is all over the web. It's my first name dot last name at Microsoft, so not hard to find.

My Twitter handle is my first initial and my last name, so APardo, although while I am older in spirit than Ankit, you had Ankit Asana on recently. I actually know what Twitter is. I don't tweet much, but you can find me there. But I'm pretty much all over the web, not hard to find. And if you're going to be in, I'm going to mispronounce this, Oulu, Finland, next week, stop by and say hello. I'll be sitting in EWG. Okay, great. Thanks so much for coming on the show today. You're welcome. Thank you. Bye. Okay. Great. Thanks so much for coming on the show today.

You're welcome. Thank you. Bye. Thanks. Bye. Thanks so much for listening as we chat about C++. I'd love to hear

what you think of the podcast. Please let me know if we're discussing the stuff you're interested in or if you have a suggestion for a topic. I'd love to hear that also. You can email all your thoughts

to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. 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 is provided by podcastthemes.com.