CppCast - Simplifying C++

Episode Date: May 28, 2019

Rob and Jason are joined by Herb Sutter to discuss C++20 and some of his proposals that aim to Simplify C++. Herb Sutter is an author, chair of the ISO C++ committee, and a systems languages architect at Microsoft. News No one knows the type of char + char C++ Now 2019 Trip Report, Extension Points and Summer Opportunities JSON Link Herb Sutter @herbsutter Herb Sutter's GitHub Sutter's Mill Links P1000 - C++ IS Schedule P1185 - <=> != == P1186 - When do you actually use <=> Keynote: De-fragmenting C++: Making exceptions more affordable and usable - Herb Sutter CppCon 2018: Herb Sutter "Thoughts on a more powerful and simpler C++ (5 of N) C++ Coding Standars: 101 Rules, Guidelines, and Best Practices Sponsors PVS-Studio Facebook PVS-Studio Telegram PVS-Studio Twitter JetBrains Hosts @robwirving @lefticus

Episode 200 of CppCast with guest Herb Sutter, recorded May 28th, 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, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice, CLion, ReSharper, C++, or AppCode. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com. In this episode, we discuss car arithmetic and a new JSON library. Then we talk to chair of the ISO C++ committee, Herb Sutter.

Herb talks to us about his goal of simpl for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I'm doing all right, Rob. 200 episodes, pretty crazy. I know. I can't believe we've been doing this for four or five years, however long it's been. I guess for like four and a half. See, we should have known how long it had actually been before we got on the air. Yeah, we're just doing the math because it's been about 50 episodes a year. Yeah.

And then we started in February, so it's been more than four. And I joined you in June, I think it was. Okay, so it's probably been about exactly four years that you've been doing the show with me. That sounds right, yeah. Yeah, that's another big milestone. I wonder how much longer we're going to keep this thing going, man. Do you have any plans on stopping? I don't have any plans on stopping.

I mean, and C++ is still staying very active, so there's no reason to stop. Yeah, you know what? I do stop. So, yeah. Yeah. Yeah, you know what? I do a lot of travel that comes up. And, you know, I'm going to take a moment to just mention this. I don't think I've mentioned this on the air. Maybe I have. But it happens every single time, pretty much every single time I'm on an airplane.

Someone decides to ask me, what do you do? Oh, I'm a trainer. What do you teach? C++. Oh, you're a dinosaur? Or, yeah, it happens like constantly. I'm like, actually, no, there's like millions of people. Like, here, let me see your cell phone.

Let me show you all the apps on there that are written in C++. You know? Anyhow. And are these actually like technical people or? Oh, the last guy, Ran, owns a software company. And he thought C++ was's boss was dead oh yeah i mean i guess amongst like the newer programming language communities like javascript and things like that maybe they're just not aware of what's going on i don't know he had actually been running this

company for over 20 years so i really don't understand but yeah it happens so regularly that i just uh i often will just say i'm a YouTuber when people ask, and then I carry on. Okay. Well, at the top of our episode, I'd like to read a piece of feedback. And we got a couple emails when we announced who we were going to have on for the 200th episode. And this one is from M. Limber, saying, You asked about questions for Herb Sutter. I've always wanted to know more about his background.

Where did he go to school? Where has he worked? What projects has he worked on? How did he get involved in C++? How did he work his way up to the chair of the committee? And what happened to the mustache? He has two great images of him. One where he's posing next to the long visual C++ box.

And I think we'll just jump right into introducing Herb so he can answer this. Herb Sutter is an author, chair of the ISO C++ Committee, and systems language architect at Microsoft. Herb, welcome to the show. Thanks for having me. I love that question. That's just hilarious. So do you want to start off with the most important one? How long has it been since you shaved the mustache off? 2002. I love that question. That's just hilarious. So Jonah started off with the most important one.

How long has it been since you shaved the mustache off? 2002. But I didn't change that picture for quite a few years. It was really great. There was a period in the 2000s where I could attend conferences. And until after I'd given my talk, I could be anonymous. And then that period after I gave a talk. That only worked for a few years, though.

That's awesome. Do you have any quick answers for some other questions? Like how long have you been working in C++? How did you kind of get into it? Oh, I got into it fairly early as far as the commercial world goes. I went to University of Waterloo, so I'm a Waterloo user. And a great, great technical program. I was there in the 80s, and one of the things I really appreciated about it, which is still growing strong today, is that it's a co-op program. So basically, if you do, say, B-Math,

it was in my case, so with a computer science degree, instead of it being a four-year degree, it is a four-year degree, you a four-year degree you get all that coursework but because they alternate four months of school term four month work term and so at the end of it you have eight your full eight terms of work of academic work but you also have six terms of experience so it takes a year longer but basically all your summer work that you would have done summer jobs are experience in your field so you so it takes a year longer, but basically all your summer work that you would have done summer jobs are experience in your field. So it takes one year longer, but you graduate with two years of actual work experience, which I found to be really helpful because I needed to make that transition. It was hard from being a solo coder to actually working

on a team on things other people tell you to work on and to make that be fun too so yeah and then i got into c++ because of and having to write software where its values were important i did a lot of c fortran and those kinds of things but then especially when it was time to start my own small company we needed to have a higher level language. And so C++ was the natural fit for us. But we also needed a container library. And at the time you had the Rogue Wave one, you had all sorts of OO style dynamic ones.

But there was this new thing called the STL that had just been voted in by the committee that had no implementation in the world except for the original HP raw sources and Modena's implementation. And we took a bet on it. It was probably silly, but it worked out at the time that, you know, being rational, but we were exuberant and it worked out really well. So we probably worked on one of the first commercial projects in the world to use STL because I wanted to adopt it. And the funny thing was we used the implementation,

initially HPs, but then also the ones that came with the compilers, but we bought Modena's STL. We did not use their implementation. We just wanted their manual because there was no good write-up of how to use the STL. And it was worth buying Modena just to get the manual. So, yeah, it was probably more bleeding edge. But, hey, we were young.

It was the 90s. Wow. So from there, then, how did you end up as chair of the C++ committee? Oh, my goodness. I have no idea. The main thing that sort of was a pattern in the things I did, becoming a columnist, first a published article author, then a columnist, then giving talks at conferences, is that I didn't plan to do those things. I started off

just by writing little puzzles internally in my company and then posting them on Usenet about the C++ things as I was learning them because I found that the best way to make sure I learned something was to write about it because you may think you know something in your head, but as soon as you try to explain it to somebody else, oh my, you need like another level of knowledge. And it was rewarding and entertaining for me. And then Bob Martin, who was the editor of C++ Report at the time, said, hey, well, why don't you write this as an article? Because I'd written a particular piece on exception safety. Oh,

okay, sure, I'll do that. And I wrote a two-part article. I'm all excited. I got to write for C++ Report. And then he said, hey, you're writing all these. Why don't you write a column? Really? Cool. All right, I'll do that. Hey, we're having a C++ World Conference. Why don't you come give a talk? So I did. And largely, that's how I started doing all those things. So I've always tried to do the same thing for others, too. They may not even know what they're good at. Suggest they give talks at conferences. Suggest they write up a blog post explaining their idea. You'll be amazed sometimes at the reaction you will get. They just didn't know that that was okay or that that was something that they could do. And the community as a whole will really benefit. So that really taught me an important lesson.

And Bob Martin in particular did a lot of that. So I really appreciate that as well as others in the committee were very welcoming and inviting. Yeah, it's great advice. You don't need to ask permission from anyone to become an active member of the community. Just go and do it. Yeah. I'm curious, those articles you're referring to, that was your guru of the week articles. Is that right? That's right. Yes. Over 200 of them. Over 200. Yeah. Well, I remember referencing them when I was first learning C++ in the early 2000s. So thank you for those. Oh, you're welcome. Thanks for being interested in reading them. That always encouraged me to write the next one.

Okay. Well, Herb, we got a couple of news articles to discuss. Feel free to comment on any of these, and then we'll start talking more about your current focus with C++. Okay? Sounds good. Okay. So this first one we have is an article by Anders Knotton, who I believe had on a while ago. And it's no one knows the type of car plus car, or char plus char, depending on your pronunciation. Care plus care care let's just argue about that for the next five minutes yeah so oh i love this article yeah it was interesting um so basically the idea is he has an overloaded function that takes an unsigned int an int or a char and if you call it with a char plus char as the argument which one actually gets called. And it can be different answers depending on your compiler, apparently. Yeah, I read the title, and I'm immediately like,

eh, it's int, integer promotion rules. I know it's int. Right. But yeah, I was wrong. Oh, unless it's unsigned. Unless it's unsigned, and they are the same size, right? Right. Well, yes, right. I thought this was really an interesting article

because as soon as i saw the title i thought okay i know at least half of what he's going to write about because the shorter the slightly shorter title is no one knows the type of char like that right there tells you most of what you need to know because you don't know if it's signed or unsigned, whether it's smaller than other built-in types. But I liked – I was intrigued that he said, no one knows the type of char plus char. And I thought, you know, I'll bet there's stuff here I would need to think about before answering, and I was right. And just adding that one extra little wrinkle really helped give a nicely illuminated discussion on such a short article like a two-minute read but it has so much in it so i i love that kind of thing thanks anders yeah great article okay and then and by the way i i can't let that one go by without saying

that you know we love c to death and the fundamental types, they work. But man, C got the fundamental types wrong. And so that's too strong. Let me say that again. It got the fundamental types right, and it was an important advance because nobody thought that you could have a portable language with such fundamental types that you could actually run portably, at least on PDP-style systems. And it was a huge success. With 30, 40 years' experience, we realized that char is not another arithmetic type. You should not be able to add chars, hence the title of this blog post. You should not be able to plus-plus a char. The fact that it's implementation-defined, whether char is signed or not shouldn't even be a thing

there shouldn't even be anything about sign it should just be a character no arithmetic and all you can do is character like things and then an 8-bit int is a different type that's when you can do arithmetic on but not character like things so they're kind of jammed together so that these fundamental types are all for arithmetic together. And if we ever could take a breaking chain someday in the future, it'd be nice to clean that up and just make char for characters and int for integers and never the twain shall meet. Okay, so I'm curious now. If char, car, care, whatever, if it was not an arithmetic type at all, would it still support comparisons? Like, would we be able to say, well, if this is greater than A or whatever?

Of course, of course. Now you have to talk about things like the encoding. So assume that care was an 8-bit UTF-8 thing. Then you could totally define what the comparisons are for individual characters in 7-bit ASCII, for example. And since we're talking about it, for completeness, there are really three fundamental 8-bit kind of things, assuming a minimum 8-bit byte for simplicity for now. There's an int8, which is an 8-bit integer. You should be able to do arithmetic, plus, divide, plus, plus, those kinds of things.

There's character character which stores characters and you can do less than that kind of thing on both of those but not integer arithmetic on characters and then there's byte which is just raw storage and only that one should support bit operations uh directly i mean in unsafe code you can reinterpret casts and do bitwise on the others. But if I had a blank slate, which none of us do these days, I would make those three separate things, byte for raw storage and bit operations, care or char for character operations, and then, and say something about UTF eight there, and then have int and unsigned and float for actual arithmetic and number operations. So where did the explicitly sized integers fall into that hierarchy, I guess, like int32 or uint32?

Boy, we are off on a tangent, but a delightful one. Okay, so you're making me say the whole thing, so I'll say it. If I could revamp the fundamental types, I would have byte, which we have since C++17 as described, bits only. Char, which defaults to char8, but have char8, char16, char32 as well, all one word. But you should have a default, So char can be the synonym for char 8. And then similarly for int, int 8, int 16, int 32, int 64, int 128. Same for uint, for the unsigned ints. And then for float, you have float 16 because you want half, float 32, float 64, float 80, et cetera. Then you have these families, and you never, in this scheme,

when you have to create a new one next decade that's a bit bigger, you never need to go long, long, long. You just go float 256 or whatever is the appropriate thing. So that's if I had a time machine, which none of us have. Right. Okay, next article. This is a trip report from Jean-Huidh Manid, C++ Now

2019. It was a pretty interesting trip report. I think he also got one of the awards, or one of the runner-up awards for best presentation, which we mentioned last week. He took on a bit of a leadership role. Apparently, he didn't

plan on doing this, but he was made in charge of all the other volunteers. That's what happens when you are a returning volunteer apparently. Right. And he also announced that he's going to be doing the Google Summer of Code over the summer and working on some possible

changes to Vector of Bull and making a bit iterator. Is that how I'm reading this? Right. Does that sound right to you guys? I don't know. I missed that. You missed this at the end?

Yeah. He, he talks about how he's working on observations that Howard Hennant made seven years ago about how vector of bull is great, but it's a terrible name. And, uh, there is a proposal that he's going to be working on.

Hmm. Very cool. Yeah. Yeah. Yeah, I somehow missed that paragraph. I read the one after it and the one before it. I wonder how that happened. Have you heard about this bit iterator proposal, Herb? A little bit, yeah.

There's various bit-related things going through the committee, and it'll be interesting to see where this one goes. Of course, byte was the one we already referred to that we got into C++17, and now building further on that and the kind of bit vector style that we had already, people are taking another look at how to do this in a modern way. And then the last thing we have is a GitHub link. This is the JSON link library, and it's a JSON handling library. It looks pretty nice to use. You just need to write a serialization and a deserialization free function for your class, and then it seems like it's pretty easy to convert to and from JSON. Yes. What stood out to me is that a lot

of these techniques look like, well, a kind of unintentional, I think, ties back to John Heade because of his Sol work with his Lua bindings. It looks like language binding stuff. Like I've done with ChaiScript, like he's done with Sol, like Boost Python, but it's just for exposing your types to the JSON parser. I like the, in theory at least, I like the technique. Herb, was there anything else you wanted to add with this one? Well, I haven't looked at this in detail. I took a quick skim of it before we started the call.

The one word that does not appear on the page is reflection. I will be very interested to see how in the future, when we have standardized reflection, this affects these kinds of proposals. Because the JSON parser is your meat and potatoes reflection 101 style of example. And it'll be interesting to compare some of these great efforts like this one and compare the code side by side, the implementations and the using code side by side when we do have reflection. So very excited to see that coming. Yeah, I want to see code like this become one line when we have reflection. So very excited to see that coming. Yeah, I want to see code like this become one line when we have reflection.

Okay, well, Herb, I think we want to mostly focus our conversation today on some of the recent talks you've made about simplifying C++. But before we get there, maybe to start off, we had you on like three years ago, and it was right after the Ulu meeting when C++ 17 went feature complete. And we're now basically at that stage with C++20. So I just wanted to know how you felt about the kind of upcoming C++20 release. Well, this is always an exciting time in the standard

cycle because every three years, so here we are again, we're saying, hey, we're feature complete on the next standard. And because we're on a regular ship cadence now where we pick the time that we're going to ship every three years, you give up picking what features are necessarily going to be on it. We used to do it the other way. Pick the features, and then you give up on predicting what time you're going to ship. We like this way better. But it does mean that you tend to get regular medium-sized releases, not so much big, small ones. But some are bigger than others if a lot of things just happen to land at the same time.

And, man, that is C++20. It's the biggest release that we've had in terms of adding new features since C++11. And, again, that's not because we compromised on going back to feature-based releases. It's we're on time-based releases. But a lot of things landed after long gestations as needed for important big features. So we have the triple Cs.

You could say C++ with more Cs. We have concepts. We have coroutines. We have contracts. And even some features that don't start with C, like modules, which is a really big one.

And Spaceship. So I got to contribute a little bit to that, too. So it's going to be a very interesting release, but we're not done yet. We have a year's worth of work left to do, three more meetings to fit and finish, to do the international ballot, do bug fixes and issues processing, get it release ready, and for compilers to implement it. There's no compiler yet that implements all of Draft SQL 20, but hey, it's only 2019. So I'm looking forward to next year

having at least one, maybe more. And that seems to be our new normal with the compilers tracking the standard ever more closely. When did you become the chair of the committee? I'm just kind of curious for some historical perspective on this. Oh, it's been the better part of 20 years now. Just make me feel. Oh, wow. Sorry about that. Well, 2002. So I've got a few more years before I can say 2-0. But it was 2002. And there was a year where Bill Plogger took over again and helped out. So thank you very much again, Bill, around 2008, 2009. But apart from that one year, I've been at since 2002. Okay, so that is actually great for the question that I wanted to ask then.

Looking back to C++11, which took effectively forever to get out, did you actually think that you were going to make C++14? How sure were you at that moment? And I assume your confidence is now building that this will actually be a three-year release cycle. But I'm kind of curious about 14. Well, it's funny. I actually was very confident about the C++14 because in 2012, after several years of me nagging the committee and others supporting me, I couldn't have done it without the help of others as for any important change, I was nagging them to say, look, we should go to time-based releases. And I was kind of pushing

for every two years as well. The committee settled on, okay, we'll do it, but we'll make it a three year cycle. And as soon as they agreed to that in 2012, I knew we were going to ship C++14 on time. It was just a matter of, especially that first cycle, since it was new to us, making us stick to it. And the committee allowed new to us making us stick to it and the committee allowed me to make them to stick to it and resist the inevitable oh and this is how it always begins the camel's nose oh if we had only one more meeting we could you know increase the quality on this just one more meeting and of course as soon as you do that somebody says well my little feature only needs one more meeting oh we might as well put that in too.

And before you know it, C++ OX is 2011. That's exactly how it happens. So it is so important. And I had email again just in the past week about C++ 20. It is so important. No, we don't do that anymore. We don't take slips. And as long as you stick to that, then you'll be on time. But it's

also because of huge work by the committee to get the features ready and to stick to those deadlines. And we've done a better job in C++20 of actually having a paper, P1000 for the first time, that lays out the schedule and we stuck to it. So we're getting better as we go. So it was even more nailed down in C++20 than in 17 and 14. All right. So it sounds like it's a real plan now. Yeah. Yes. Take a look at P1000. There was a reason it got the nice, easy to remember number. Right. Thank you to whoever else gave up their paper number so I could get that one. Okay, so you've publicly stated in a couple talks, I think, that your goal is to simplify C++. Do you want to tell us a little bit more about what you mean by simplifying it and why you think that goal is important?

Every important language gets to a point where you have to really evaluate what is the cost, the incremental cost of adding an incremental feature. And we're certainly not done adding features, but we're certainly at the point, yeah, look at C++20, right? But we're definitely at the point where we should be starting to say, you know, it's time for going back and making sure that what we're doing is being done at high quality, that the stuff we have now we're going back and doing maintenance on, and that we take a look at, to paraphrase the famous essay on English as she has spoke, C++ as she has spoke, how is C++ actually taught, learned, and used? And we might add to that, tooled and maintained in the trenches. And how can we make that better? So it's not just a matter of getting a smaller language. So one of the reasons I'm very keen on getting reflection progressed,

I'm glad the committee seems to feel the same way, is especially with reflection and then also generation, the flip side of it especially with reflection and then also generation, the flip side of it, to query and to generate code. I think we could actually get rid of many proposed language features and not add them in the future, which will help simplify C++ going forward by inventing fewer special purpose features in the future. But it'll also help write things that we already write as patterns today. We just were looking at a few minutes ago at a JSON parser. I love this project, and I resisted saying yet another JSON parser because how many are there, right?

That's not a ding at all against the project. This looks like it has some really cool ideas that we haven't seen, but we keep inventing these. We keep doing things that other languages have had standard for a long time. And yes, reflection is slow and C-sharp. But you know what? It's useful. It gets the job done, and you use it when you need to. And there's a lot that we can do if we are very thoughtful about cleaning up the language

as we have it today, including things like exception handling that people routinely turn off, we should listen to that as data, not say, oh, they're not doing it right. But if they keep persisting, perhaps consider that maybe they have reasons to do that and see if there's something we can improve about the feature we have and be thoughtful about the features that we add to see are they general ones that we can use as a foundation to build more things as libraries. And that's, again, why I think reflection is an important one, because it will let us write more things as libraries. And that's what C++ is about. I mean, we are the system's library building language. That's what we've always been about. That's not a new charter for us. That's core we've always been about. That's not a new charter for us. That's core to our charter.

And so I think it's something that fits very well with C++'s mission and will help us to be less inventive and invent fewer and narrower features, which will just help use C++ in the future. Okay. So do you want to dig into some of your specific simplification goals. I know that one of the first ones that you mentioned is C++ core guidelines, which is something you and Bjorn have been working on for a few years now, right?

That's right. It turns out we both had about the same idea in around 2014, early 2014. And what we wanted to do was say, you know, there's all these different, one of the parts that's complex about C++ is you have all these guidelines all over the place. And some of them are very in quality. They're definitely repetitive. Here's an opportunity to simplify by, if we can, taking n things and reducing them to one. That reduces concept counts and the things you need to learn the language. So that I can say, oh, if you're learning C++, where do I go to find guidelines?

Instead of saying, well, look here and there, and then that book has some good ones and read them all, that they're in one place. And so Bearda had a similar idea. And so we combined forces and with the help of other editors that we really appreciate their help, Gabriel Dostreis, Sergey is a great contributor, and Neil McIntosh, others. We created the C++ core guidelines. Andrew Pardo and so many others, and Jonathan Wakely have been, I could go on, have been key contributors to that. And the goal there, again, is simplifying learning C++. So instead of saying, oh, I got to go and look in these 10 places and sort of mentally assemble the information, which is not really a reasonable thing to ask a new person to C++ to do,

to have them in one place. And yes, they're pretty long, and we could even have a sort of an even smaller prioritized guide that could come out of that. But at least they're in one place, and they're easy to reference, including by tools, so that a tool can say, oh, you violated this particular rule and actually give you a link to the live guidelines. So that was part of the intent there. So hopefully that's helped simplify learning the best practices.

The goal was also that individual companies be able to adopt it. And we've seen progress on that. Several major companies are in the process of rebasing their coding guidelines on it. The latest issue that was just opened up yesterday, last night on the core guidelines repo was from the office team, I think it was at Microsoft saying, hey, we want to rebase our core guidelines on these with just a very few exceptions for us. Could you change this detail about how you do it so it fits into our workflow? Which is a great question to have because it shows adoption. And so I am hopeful that's helping at least simplify learning the C++ we have, even as we want to improve the C++ we have and tactically add more things still. I'm curious how you see the guideline support

library also fitting into that, which I honestly, I often forget that the guideline support library is there, and I really should be more aware of it in my own code. Well, and I think that's a key thing, and it's also key that it's small. And so there's more than one implementation. Microsoft does have one that a bunch of people use, and we need to catch up on our PRs for that for sure. But the guideline support library is actually quite small, and it's about things that, for the purpose of writing the guideline advice, we wish was in the standard but isn't yet.

And so there are a very small number of things that we could propose for the standard, like a handful or two. One of them has just been standardized in C++20 in a different form, which is usual as standardization refines things. But the standard span comes directly from the guidelines array view. And so as it's been standardized, we've been tracking the names and the styles largely in the guidelines in the GSL. And then as those things get standardized, we can just drop them from the GSL. That's the ideal case. And not everything necessarily needs to be standardized.

But if you have things like narrowcast, if they're not standardized, hey, at least they're still in the GSL. But it's just a very small number of things that are very general and very broadly useful. So a small number of things that you can use a lot. All right. And then at CBPcon this past year, I think you made some announcements with the lifetime checkers, right? That's right. It's nice to see that there is now implementation in the Visual C++ product as a static analysis extension, and also in Clang, which is now in the process of being upstreamed. I just blogged a month or so ago about a nice talk that was given by Matthias and Gabor at

URLLVM about progress there. So yeah, check the blog. It has a nice link to that YouTube talk. And I appreciate very much their help in getting this out there. It's just going to be really nice once we can just regularly assume, you know, some number of years from now, that just like every compiler has warning about, you know, a certain common thing so we don't have to teach it, that they'll

also have common warnings about common classes of dangling so we never have to remind people hey, you invalidated your iterator in a loop because you did a pushback on a vector you're iterating over. And we won't need to teach that if all of our implementations always

warn on it. And so that's my hope is to, again, making C++ simpler in that case by removing some sharp edges that are common causes of bugs and classes of bugs, but also are really hard to diagnose bugs a lot of the time because pointer dangling, iterator dangling, view, string view dangling, they're all the same class of problems. And sometimes they can be really hard to figure out because the actual crash may be sometime after the thing that actually was the bug, and you may not even see it in source code. So the more we can just diagnose those,

tell people at compile time, hey, line A, you're using an iterator that was invalidated on line A minus two. That will just help using C++ so much. And just as we're in our inner workflow as programmers, be able to have less fear and more certainty about what we're doing and confidence. Now, make sure I heard you right. You said Visual Studio's static analyzer is now also shipping with some lifetime checkers? Oh, yes. Yeah, that's in the shipping product. Just go to download the static analyzer extension. And the lifetime rules are off by default. So you'll have to go and click on the checkbox to enable them. And it's granular. There's like two or three subsets of the rules you can turn on because some of them are them against old code, use a subset of the rules, just because the old code may not be written in the modern style, and it may be fine, but you may not want all those false positives for old code, whereas you might want new code written in

a modern style. Yeah, when you said it was noisy, I was wondering, is it noisy because your code is wrong, or is it because of false positives? Well, it's very much much now the lifetime profile is actually part of the c++ core guidelines and they both share the same view that they have an opinionated view that word appears in there on how code ought to be written that means that some legal code that you can argue is you you know, in quotes, correct, like doesn't have bugs today, is actually not allowed by the core guidelines or by the lifetime checker, because there is an easy way to write it a different way that is much easier for people as well as tools to show is correct. Now, having said that, if you've got 100,000 lines of legacy code written the other way,

and it doesn't have actual bugs today, you're not doing anyone a favor by just having a lot of noisy warnings. It just means you'll be ignored, including the ones about real bugs that you could be checking. But when you write code going forward, if there's no reason to write it the other way because you have an equivalent way that's easier for humans and tools to understand that's just as good and just as safe. Well, then you should write that. That's what some of those warnings are about encouraging. So there's a distinction between old code and new code. You want a superset of the warnings for new code because it's about this modern style that's just easier to read and tool. Right. I want to interrupt the discussion for just a moment to bring you a word from our sponsors.

PVS Studio is a tool for detecting bugs and security weaknesses in the source code of programs written in C, C++, C Sharp, and Java. It works under 64-bit systems in Windows, Linux, and macOS environments, and can analyze source code intended for 32-bit, 64-bit, and embedded ARM platforms. The PVS Studio team writes a large number of articles on the analysis of well-known open-source projects. These articles can be a great source of inspiration to improve your programming practices. By studying the error patterns, you can improve your company's coding standards, as well as adopt good programming practices which protect from typical errors. For example, you can stop being greedy on parentheses when writing complex expressions

involving ternary operators. Subscribe to Facebook, Telegram, or Twitter to be informed about all publications by the PVS Studio team. Links are given in the podcast show notes for this episode. So then another thing, you already kind of brought this up with C++20, is your spaceship comparison proposal did make it into C++20. And that also kind of falls within the realms of trying to simplify C++, right? Yeah, so I'm very glad to see that into the current, the next standard, 20. And basically, that's all about simplifying the way we write comparisons.

This is a very narrow feature, and it builds on work that's also been done and re-invented in other languages. The idea is all these functions, equals, less than, not equals, greater than, equals, they're not unrelated. In C++ pre-20, they're just unrelated. Oh, here's all these operators you can write, and so you have to write them by hand. And there's a lot of duplication there. There have been attempts, like the relops work from the very beginning to remove some of that duplication, but that wasn't a successful way to do it. And so relops was buried in a relops namespace where most people don't even know it exists anymore, even though it ships with every

version of the standard. So instead, what this does is it says, hey, you know, there's an abstraction that's missing. If you have a three-way comparison, then you can use that to synthesize all the others. If you have that comparison, you can write one typically. And sometimes for optimization, you might want to write equals separately because it can be faster than a general three-way comparison. But you should be able to write just the spaceship operator and or the equals operator and synthesize the rest. And so instead of writing anywhere from two to 12 comparison functions by hand for every type you write, you would write one or two. And also with a better expression of your intent, because spaceship can actually return, am I a strong ordering or a weak ordering or a partial ordering,

and actually encode that in the type system, which is useful. So it simplifies how you use C++ just for this general and commonly recurring pattern of just writing the comparisons. You can write a lot less boilerplate. And it looks like we're actually going to adopt it in the standard library in C++20. I didn't know if that was going to make C++20. It looks like the standard library use of the feature might make it. We'll see.

But it looks like it will shorten the standard by a little bit as well. Oh, nice. So when the spaceship proposal was first accepted, I saw some articles, people talking about, well, in such and such case, this isn't necessarily the 100% correct thing or the most efficient option that we could be doing. And I believe some feedback was sent back to the committee and the papers. Those kind of things have been addressed, and I feel like now that I said that out loud, I don't even really know what I'm talking about. But I'm guessing you might. Yes, you do. So, yes, that feedback was addressed. It really

boiled down to one specific thing, which was in the proposal from the beginning, but improving the support for one particular thing. And that's the part I mentioned about sometimes you can write equal equal more efficiently than a three-way comparison. The canonical example is vector. If I'm comparing two vectors, if I have to do a three-way comparison, then because a three-way comparison returns whether one is less than, equal, or greater than the other, right? So that means I have to actually look at the elements of the vector and do a comparison to find at least the first one to see if it's less than or greater than the first element of the other vector, and so forth, until I find one that's not equal. Only then can I tell you whether it's equal,

less than, or greater than. But if I'm writing not three-way comparison, but just two-way equality comparison, equal, equal, without even looking at any contents of the vector, I can first cheat, cheat in air quotes because it's not really cheating, and look at dot size. If the sizes are different, I don't need to look at any elements of the vector because I don't care if they differ in the millionth element because one's longer than the other at the very end. I know they're different. I can short circuit that whole thing. So that was in the paper from the beginning that you can write spaceship and overload equality for cases like that. Okay. write spaceship and overload equality for cases like that. The issue that came up is it was easy to lose that optimization when you further composed things.

So let's say I wrap a vector's comparison. I have to remember to know that, oh, look, vector did that. I should, in my wrapper type, also overload equal to equal. And if I don't, if I supply only spaceship, then I lose the optimization. So the extra work in two papers in particular by Barry Revzin with a lot of input from others, David Stone and others, P1185 and 1186, funny how these numbers roll off your tongue after you've been reading them for a long time. 1185 and 1186 are fundamentally about that we preserve and chain and propagate.

If one type provides a specialized equal-equal, we'll remember that and automatically apply that, say, when we wrap it with something that provides its own spaceship and so forth. And that way we don't lose the optimization. So that fix has been done. It's been working very well. And I'm very heartened that as people show more examples of, oh, by the way, we get to narrower and narrower corner cases. What about this code?

It actually might change meaning in C++20 because we're synthesizing the operators symmetrically, which is part of the spaceship proposal, which we didn't used to do. More and more we're finding, A, they're very edgy cases, and B, most of the time, they're code that wasn't right before. It may have, air quotes, worked, but you mean seriously? You provided an equals and didn't provide a not equals? Or you provided an equal equal A comma B and you forgot to provide an equal equal B comma A? We're now helping you by diagnosing where you're not doing it right already.

And that's a good sign that we're standardizing the rules in the language now. We're elevating what in the past has been an idiom that we teach as a series of rules. When you overload operators, don't forget to provide symmetry. Don't forget to implement one in terms of the other, etc. And now we just elevate it into a language feature and do it for you. And it's nice that as icing on the cake, the rules also, this is an unintended side effect and bonus, will also diagnose irregularities where it's been done irregularly before and say, did you really mean that? And so just recompiling existing code with a C++20 compiler will make it better for comparisons, even if you don't use Spaceship.

So I'm very optimistic and looking forward to seeing how that gets adopted and just writing fewer comparison operators. Here's a trivia question for you. I said that you write just one or two, two if you want to optimize, instead of up to 12. Why 12? Because there's only six comparisons. Yeah, I was wondering about that. I don't know why there's 12. Because for heterogeneous comparisons, when you're comparing two objects, different types like A comma B, you have to remember that to make them symmetric, you have to provide a

comparison for A comma B and one for B comma A, so that you get conversions and so forth. And it's symmetry on both sides, so that when the user writes A equal equal B and B equal equal A, they both work. And that if there's conversions A equal equal my string, that string equal equal my A, that symmetry also works. So you have to remember to do that. I'm glad that I don't have to teach that anymore once we have C++ 20 compilers out there. Yeah, I'm sure Jason's glad too.

Yes. Don't worry, there'll be lots of new things you can teach. 20 compilers out there. Yeah. I'm sure Jason's glad too. Yes. Yeah. Don't worry. There'll be lots of new things you can teach. Well, besides the fact that, I mean, it's, I mean, companies seem to be on about a six or seven year lag

for adoption of C++ standards. So I'll probably still have to be concerned about these things for a little while. Right. But all of these things are the common pattern of if I get a common compiler warning, if I have language support to do it a simpler way, the common theme is I can teach less stuff about C++. Right.

The core guidelines, if there's certain warnings that I can just assume are everywhere, I don't have to teach it. The lifetime warnings, if I can routinely know about invalidated iterators and pointers for common classes of errors, I don't need to teach them. If I have Spaceship and I can just tell people, write this one function, or for optimization, write this other one as well, if it matters, and I'm done, I don't have to teach a page full of other rules. And that's the kind of C++ I would like to see us moving forward to more in the future and really embracing that and taking to heart about how can we teach less, not by dumbing down the language because we want to do as much as ever and more, but why all the boilerplate?

How can I express my intent more directly? Then I have to write less code. I could write more of what I want to express rather than language gymnastics. Yeah. Okay. So we've mostly talked about some of these simplification topics that are already kind of a part of C++. But there's also the reflection proposal, which kind of goes with your metaclasses proposal. Do you want to talk a little bit more about that?

Yeah. proposal, which kind of goes with your metaclasses proposal. Do you want to talk a little bit more about that? Yeah, we covered a lot of it, which is, my hope is we can write, we can invent fewer future language features, because for instance, one that we're talking about now, I mean, Vila and I were talking about this when reflection first came to the committee in the past two years, 18 months or so. And Vila Votelainen, he's the chair of the Evolution Working Group now, and he said the same thing I was thinking was, well, I can see about eight proposals that we have on the books right now that we could just not think about anymore if we had reflection, because

we wouldn't need those features, so we can just stop talking about adding them, which helps not increase the complexity of the language. One example is Operator.dot example is Operator. So Operator. was proposed for C++17. It did not succeed. The idea is to be able to write smart references and smart wrappers that can forward.

So if I write a wrapper of T template, right, I can provide like a.get to get at the T. But I can't, if the T type has its own foo and bar functions, I have to write my wrapper dot get dot foo, dot get dot bar. I can't just directly say wrapper of T dot foo as if it was a T because it doesn't have all the same functions as T. And there's, in general, no way to do that, including by contortions like inheriting from T, to make it have all the right functions of T and to be able to do the wrapper thing as well. With reflection and generation, it's pretty easy. There's an example in my metaclasses paper, 707. It's like four lines of code.

You just say for each function in the class, generate one like it that calls the original. And now you've duplicated the interface of T. So things like that get a lot simpler. I think that once we can do that, we don't need operator dot as a special language feature. And the nice thing is of all of that is that if we had reflection so that you could do that, any user could write that wrapper functionality without even waiting for us to standardize it. Whereas if we did it through operator dot, they would have to wait for every compiler vendor to implement this language feature, which would cost a lot more and take longer before they could use it. So the hope is that that's an example of how enabling us to write more libraries instead of language features can help simplify language evolution and just make C++ easier to use. And you don't have to wait for the standards committee to get around to standardizing your favorite feature.

It won't do all language features for sure, but many ones that are class-related like that, that are based on generating things based on what else is in the program, those can be simplified away, I think. And it's been proven out very well in other languages. So how, well, what is the current status of metaclasses for C++ 23, I guess? Well, the right way to think about it is there are three components. There's reflection, and that TS has been published. And we are now looking at learning from that and having a more efficient implementation that's been work done by myself, Andrew Sutton and David van der Voort and merging those things.

That's going through committee. So we have a solid foundation of efficient reflection that doesn't blow up your compile times. You also need constexpr programming. Hello, Jason. And constexpr all the things so that once you reflect the information, you can drum roll, do something with it. Right.

And generate things. And once you have those two, metaclasses is a thin layer on top. a compile-time function that takes a type and reflects on it, all metaclasses is is syntactic sugar for being able to define a class that invokes that function on its own body as you write it. It's like 90% of the work is in reflection and compile-time programming. 10% of the work is in metaclasses itself. The reason the metaclass proposal was so big is because at the time I started writing it, we didn't have reflection. We didn't have enough compile-time programming. itself, the reason the Metaclass proposal was so big is because at the time I started writing it,

we didn't have reflection. We didn't have enough compile time programming. So I'm glad to see all of this going into the standard and standardization process, I should say. But I do hope to bring later this year, either in Cologne or in Belfast, an update to the Metaclasses proposal itself. There will definitely be updates in Cologne in about a month from now to the reflection proposals based on the Metaclasses work and brought by Andrew Sutton and David Vandervoorde that's based on the Metaclasses implementation, which is available on GitHub and is on Compiler Explorer as well. So it might be way too early to ask this kind of question, but if it looks like we're going to get reflection as part of the next standard, hopefully C++23, do you think metaclasses would be there with it, or would metaclasses have to lag behind reflection for a cycle? You're right that it's too early to tell. So it would be, we're on a time-based release cycle, where we try hard not to predict what's going to land at any particular standard.

That said, when you look at when TSs ship, it's generally a couple, three years later that they're ready to be added to the standard, depending how experimental they are and so forth. So reflection has a chance of being in c++ 23 and i'll be very happy if if that's if we get just reflection in in 23 i'll be ecstatic with that metaclasses again is a very thin layer on top of that so as long as the reflection includes generation support which is another level and that on top of just read-only reflection, then you can easily do metaclasses or something like it on top. So reflection and generation are the two things to watch for, and they'll probably land in that order. I think, kind of building on Rob's question, but also maybe just going a little bit more generic and

leading back to what you had said earlier, that you see that in the C++ 20 standard library is going to start using the spaceship operator, which will simplify the standard library in some cases. We think, yes. I have to look up to see if it's going to land in 20. We didn't think it was going to, but now it looks like it may. So I just see like in general, and I'm not criticizing this at all because these things do need to be proven out, but we get a feature, and then in some cases, we don't know exactly what's the best practices

for applying this feature in the standard library, or in some cases, like with constexpr, it seemed like no one really fully appreciated just how much constexpr we would truly want. And then I feel like no discard, like you had to see like STL's team, like deploying this across the standard library implementation to realize just how powerful no discard can be. And we end up with a three to six year, you know, one to two cycle lag of really seeing these things moved into the standard library. And while the use of them being pushed into the standard library,

do you, do you see that being compressed at all? Or do you think that this is where we need to be so that we know the best way to use these features before we like basically push them on everyone? I think you need learning time whenever you do anything new. Okay. And, and I think there's benefits to putting something in the language, even if it's

not yet widely used in the standard library, as long as we have confidence that it's baked. So at the time that we ship the standard with just the language version of a feature, we usually already have a pretty good idea of how to use it. But we also know we're going to learn more with experience. But we know enough we're going to learn more with experience. But we know enough to say, yes, we have confidence that this is the right shape and that any other tweaks we need to do to it can be done in a backward compatible way. That's an important bar for us. Occasionally, we're wrong. But so far, the bets have been mostly paid off. And so for features, for example, like move semantics, we shipped move semantics as one of the

key, perhaps the key marquee feature of C++11. And it was just great. It made your existing code run faster in many cases and so forth. At the time that shipped, Howard Hinnant, who was the primary driver of the move semantics proposal, said publicly and in writing and to the committee that nobody knows how to fully use this feature yet. We're still learning how to use this feature. That was not a reason not to ship it, but it did show that because we already knew how to use some of it. We shipped a move-only unique pointer in the same standard as that, but we did a lot more with move in the future, but without any backward compatible breaking changes, but we learned even more how to use

it better. So most features that we ship in the standard language, we do also ship at least somewhat in the standard library. So for example, if you look at C++20, we're shipping concepts. We would have been happy as a committee to ship concepts as a language feature without using it in the standard library, but we also merged ranges, which uses concepts. And there are now, I counted recently, so I happen to know the number, 68 concepts specified in the standard library, not counting the ones that are hand-wavy, implementation-specified. There's just like 68 concrete ones. So concepts are being widely used in the C++20 standard library itself, but I guarantee you we're going to use it even more in the future as we learn more about it.

But most features do get used at least somewhat that way, even though we're going to learn, as we learn them more, how to use them even better and how to tweak and improve them. For example, like Lambdas with this capture, we'll find things that we can tweak. But as long as the feature is in a fundamentally good shape, hey, ship it, we can start building on it and learning with real compiler experience. Does that sort of answer the kinds of things you're asking?

Yeah, it's also the kind of question I get from students. Like, hey, with this feature so great, why isn't it being used in the standard library yet? And I'm like, well, you know, there's a process to understanding how and when to deploy these things. Yeah. And in fairness, sometimes we have, like in, I'm pretty sure this happened in C++17, we have made the mistake of, on the language side, being really enamored with a feature and thinking that everybody knows what we're doing and putting it in the

language at kind of late in the cycle. And then the libraries folks were like, would it kind of been nice to know that was coming and you could have given us more of a heads up about that? And that was a real complaint that was made three years ago and it was legitimate. And so we've been trying really hard. If you look at paper P1000,

one of the things that we tried to do better in this cycle, you'll notice that's documented there. It's only one page long, so no excuse to TLDR it. Is that to try to merge large language features, including TS, is to try to merge them early in the cycle. Now, some of them we did later, like coroutines and modules. But some of them we did do early. Concepts was voted in at the first meeting of C++20. So there was lots of time to react to it,

and it shows in the standard library that we were able to build, to not just use it in the standard library, use the concepts feature, but to build a whole other library that depends on it, that ranges and include that in the sufficiently baked for C++20. So I think that worked really well. Can we continue to improve that? Sure. And I do not want to minimize that we've made that mistake of, oh, everybody should know what we're doing.

And here, let's just drop in another feature. I'm sure the standard library will do the right thing. So we're being a bit more methodical about communication between the language and library side of the committee. And I think it's gone quite well this year, this time through this cycle. All right, thank you. So I don't want to let you go without talking about static exception handling. I just watched your talk that you gave at ACCU about exception handling. And I wanted to know, how is that proposal coming along?

My understanding is that you didn't want to talk about it at the committee before C++20 was done. Are you going to start giving actual proposals with the ISO committee? So yeah, so that, like metaclasses, has been a proposal to the C++ committee. But I've been deliberately holding back both the Metaclasses proposal and static exception handling from Evolution Working Group, from the language design part of the committee until after C++20's feature set is finalized, which is around now because we finalized it largely in Kona. If there's a couple more things that come in in Cologne next, a month from now, it'll be things that were already approved, but we didn't get to finish the wording and vote it in formally.

So the past year or two, if you went to the Evolution Working Group, which is the main subgroup responsible for language design in the committee, it was more than full with language proposals, including for C++20, for post-C++20. You might recall that last year we created two more subgroups, incubator subgroups, for language and library evolution topics that didn't fit into the main one-week schedule for the core groups yet. And that's the overflow, and to give early feedback on longer lead and smaller proposals. So we did that. But if you went to EWG, not only would you see it was full up with work all week long, and to give early feedback on longer lead and smaller proposals. So we did that. But if you went to EWG, not only would you see it was full up with work all week long,

but we would spend probably at least three of those solid five days on concepts, co-routines, modules, contracts. Like those soaked up every single meeting the majority of evolution time, and there was nothing we wanted to do to distract from that. Try to bring your own proposal, and one of two things will happen. Like if you bring another major proposal like these, either it'll get ignored because there's no time, or it'll get looked at, which will take airtime away from finishing the features we have in process, which would be wrong. And so I tried not to bring those.

So in Cologne and or Belfast, I'll bring updates to those targeted to evolution so that if it does have time, that the evolution group can look at it. Having said that, subgroups have already seen both proposals. So SG7 has seen multiple iterations of reflection and metaclasses. The library evolution group and also SG14 have seen iterations of static exception handling. And so they're moving forward. And the

timing is right now where, okay, we don't want to distract the language evolution work on C++20. Now that we can stop pushing the pedal to the metal on that one and we have a breathing space, now it can be time to start looking at post C++20 features, even as we're going to spend some language evolution time

on C++20 to answer questions that come back from wording review, questions that come back from CD ballot that could be design questions. So we'll spend some design time, even though the feature set is closed, but there should be airtime to discuss largely post C++20 features in the evolution group. And fun things like static exception handling and reflection will be taking up a fair amount of time probably, or features like it, in the next couple of years in the evolution working group. So you said some groups have looked at it. Have there been any major changes to the Stack Exception proposal since you kind of first put it out there like a year ago? There have been no major changes.

In fact, one of the things I mentioned in the ACCU talk was that when the Library Evolution Working Group looked at two parts of the proposal, so the proposal has four parts. Two of them are specifically about library guidance as to how we should use exceptions. Basically, let's not use exceptions for bugs like logic errors, which we should be gradually transitioning to use contracts for. And also, let's not use them for out-of-memory errors, because those should be treated specially

rather than through general-purpose throwing. These were potentially controversial things. I was really surprised to find that the library evolution working groups reception was basically, yep, we're already on that path for both of those. So there were more details in the talk, but it was an interesting realization. Now, having said that, just because one subgroup of people thinks a certain way does not mean the committee as a whole does. You can easily find that now when we go to the language side of the house, they're like, what were you on when you said that? Of course you should not be doing that.

Here's a whole new round of probing questions, let's put it, about your proposal. So this is still early days for both of these. So the progress we've seen so far has been encouraging, but it hasn't hit Evolution Working Group yet. And no doubt there will be more on new questions then as proposals get to that group. So we are like right in the midst of CPPCon preparation right now. The committee is going through the papers to see who will be speaking, and registration is open. The call for volunteers is out.

And I know, Herb, you've had the chance to see the new venue, and I was just wondering if there's anything you wanted to leave our audience with about CppCon coming up? Oh, wow. I'm excited about CppCon every year, and I believe that it's true,

and I think it's proven to be true that it's the best yet every year but let me be concrete about this year the venue is is is really nice we'll finally be able to do have everything all under one roof yes it's also nice to look at but mostly that we can all be under one roof and for people who need budget hotels or something, there's lots of other hotel options that are just a short Uber ride away, just a few minute ride away just to the west there, because we're right in the middle of Hotel Alley that's right by the airport in Denver. So there's lots of options.

But many people will be able to have everything under one roof. The SG-14 meetings, all the sessions, so all the meeting time will be under a single roof, which is really helpful rather than sort of spread out as we were a little bit in Bellevue. And so that's exciting. But I'm looking at the submissions that we've got. Numerically, they're by far the largest number of talk submissions we've ever had. And I'm looking through them and I'm not seeing fluff either. It's not just because there's a lot of low quality submissions this is going to be hard

is is to drag a cut line for reference the largest number of talk submissions cpcon ever had before was last year was 224. we have over 40 more than that this year. So that means cutting like a whole other track or something like that, like a couple of tracks for that number of – that's the number of talks, just to be able to fit in the same – about 120 talks that we have every year, not counting the pre- and post-conference tutorials and things like that. So this is just going to be a really amazing program, and I'm looking forward so much to it. Right now the program committee is hard at work trying to figure out,

oh, my goodness, who do we say no to? Because it's an embarrassment of riches. So if you haven't registered, boy, go register. This is going to be a really, really cool CPPCon this year, very high-quality program and talks. And you have a track record of giving a keynote every year. Do you have any idea what you're going to be speaking about this year? Yes.

Okay. Yeah, I will most likely be giving an update of the talk that I gave at ACCU, but longer because we have more time at CppCon about static exception handling. I may also talk about RTTI because that's the other feature we need to fix in today's C++ as we do a maintenance pass that I think is necessary on today's C++. The short version is that we love C++ because it's a pay-as-you-go language, right, the zero overhead principle. And that's what we love about it.

We want to make sure all new features do that. And the only two features in the whole language that violate zero overhead that you pay even if you don't use them, exception handling and RTTI, guess what? Those are also the only two features that every C++ compiler in the world has a switch to turn off and that people do. A large fraction of the community does. That doesn't mean EH and RTTR are wrong. It means we need to go back and fix them to make them usable. And so that's likely going to be the main thing that I try to talk about at CPP Gone this year.

Cool. Sounds great. Yeah. Okay, well, it's been great having you on the show today, Herb. Thank you so much for coming on. Oh, thanks for having me. I always enjoy listening. Thanks for joining us for this 200th episode. Congratulations.

Thank you. Thank you. 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. Thank you.