CppCast - Becoming involved with the C++ committee

Episode Date: October 24, 2019

Rob and Jason are joined by Nevin Liber from Argonne National Lab. They first discuss a blog post discussing issues implementing small buffer optimizations in a constexpr context. Then they talk with Nevin about how he got involved with the ISO C++ committee and some of the proposals he's worked on. News Pack the Bits - Adventures in small_bit_vector ISO 2019-10 Mailing Meetup: Payment changes comings soon C++ On Sea Registration Links Argonne National Lab Sponsors Backtrace Announcing Visual Studio Extension - Integrated Crash Reporting in 5 Minutes JetBrains

Episode 220 of CppCast with guest Nevin Lieber, recorded October 16th, 2019. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. And by JetBrains, makers of smart IDEs to simplify your challenging tasks and automate the routine ones. Exclusively for CppCast, JetBrains is offering a 25% discount for a yearly individual license, new or update, on the C++ tool of your choice, C-Line, ReSharper C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at www.jetbrains.com. In this episode, we talk about small buffer optimization issues.

Then we talk to Nevin Lieber from Argonne National Lab. Nevin talks to us about how we got involved with the ISO committee and some of his contributions. Welcome to episode 220 of CppCast, the first podcast 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 your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I'm all right. I'm on the midpoint of a cold, I think. So if my voice sounds off or if I cut out for some reason or there's weird hacking and sneezing in the middle of the recording, you'll know why.

Okay. Well, you sound okay to me, but I hope you feel all the way better soon. Thanks. Yeah. Well, top of your episode, I'd like to read a piece of feedback. This week, we got a tweet from Bowie Owens saying, with all this talk about disabling exceptions in RTTI, I tried disabling RTTI in some code. It's picking up all the places where I've used dynamic cast. In almost every case, the code can be improved by avoiding RTTI. Next step is to measure. Yeah. So do you have any thoughts on this tweet, Jason? I think it's interesting, just the exercise of disabling RTTI and removing dynamic cast where

you shouldn't have it, you know, like, but I still don't have any problem with RTTI. But it sounds like an interesting exercise to like, find weird inefficiencies in your code or something. Well, it should like reduce the size of your binary if you can turn off RTTI, right? Yeah, but technically it's not C++ at that point. Sure, yeah. Okay, well, 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 cbcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Nevin Lieber. Hello. Hey, Nevin. Nevin is a computer scientist at Argonne National Laboratory, a C++ committee member and veteran C++ developer.

He first discovered the language over three decades ago while at Bell Labs when a friend called and asked, what do you know about C++? You folks invented it. His professional career has taken him across various industries and platforms, big data, low latency operating systems, embedded systems, telephony, and now exascale computing, just to name a few. He spends much

of his time pushing his peers, colleagues, and friends to use modern C++ constructs along the way. Looking to learn more about the language, he got involved with the C++ committee and hosted both the C++ and C-STARNs meetings in Chicago. These days, he frequently finds himself in the middle of the debates involving the more contentious parts of the standard library.

Nevin, welcome to the show. Thank you. So, Rob, when you read his name, you technically didn't read it correctly here. So, Nevin, how did you end up with a smiley in the middle of your name? I started doing that when I first started doing email back in the late 80s okay so i just kind of people expect it now so and i smile a lot so i should put that in my emails so it's nevin's smiley smiley well not emoji emoticon old style old style yeah yeah yeah nice very nice okay well nevin we got a couple news articles to discuss feel free to

comment any of these and we'll start talking more about the work you're doing with the steering committee okay sure okay so this first one is a blog post from janhid manid pack the bits adventures and small bit vector and this is kind of an interesting deep dive into him working on this itsy bitsy library and kind of struggling with small buffer optimization and constexpr. Yep. Yes. Yeah.

What's going on here? It's a bit of a ride. Yeah. I think, I want to understand for the people on the committee who've been pushing for constexpr vector and constexpr string, the small buffer optimization is problematic because you don't want to... In runtime code, right, if you're not at constexpr time,

you don't want to zero it out because that's just a waste of time. But in constexpr, that means you actually have to have everything defined. Otherwise, it's considered undefined behavior that the constexpr engine has to catch and stop you from compiling. There's also some of these problems with, like, what does your small buffer look like? And do you need reinterpret cast, which you can't do in a constexpr context? Yes. It would be nice if we could generalize how to do the small buffer optimization so people could use it.

But it's, in general, it's a really difficult part of the language. When can you type hunt? When can you put objects into existence? Especially objects that are supposed to be, the underlying model is array of things. Vector has this problem. The underlying model is supposed to be arrays except add a new element each time.

I'm not a core language expert, but I'm not sure that we can still actually portably implement Vector correctly yet. I don't know if we have enough primitives. I think we do. To portably implement Vector in general? Yes. That's nice. So for pointer arithmetic to work, you have to have an array, write an array into one object.

But Vector keeps changing the size of what that array is by creating a new element, not a new array. Right. And technically, you're not allowed to just take a... Because two objects happen to be adjacent to each other in memory, you're not allowed to take a pointer to one and add one to it to the next one. And they all do that, in other words. Right. And the committee knows we all do that. It's how do we make the standard actually say you can do this.

Right. So out of curiosity, is there anything in the works right now that you know of for making that kind of thing possible? There are people definitely looking at it. The talk I would like somebody to write, because I don't have enough knowledge to do it, is the many layers of undefined behavior in vector. But we know we need to

solve this problem. And the general type hunting problem as well. If you have elements that have references or const elements, and they go away and come back, what does that mean? Optional has the same. And the general type hunting problem as well. Like if you have elements that have references or const elements, right, and they go away and come back, what does that mean? Optional has the same, it's a little simpler and has the same issue. So someone recently told me that the standard library is allowed to invoke undefined behavior

because they know what their implementation is doing. And that didn't sit well with me, but... Yeah, yes, the standard library has the freedom. It can do whatever magic it needs to to make things work correctly. The standard library implementers do not, I mean, we'd rather not have to. We want the language to evolve, so you don't have to be a standard library vendor to make things work. Right. That would be nice, yeah. So the current situation, yes, vendors have the freedom to do it because they know the implementation.

They can define whatever they want, but they'd rather not have to do that. And there's some places we have it. Like, for instance, standard-less avoid can compare pointers, right? Put a total order on pointers. But nothing else in the standard actually lets you do that. So assuming you had somewhere in implementation that didn't totally order pointers, that would have to be magic somehow. And it can't be a specialization because that's already a specialization, right? It would just have to magically know about that one.

Yeah, I only just recently learned that standard LESS had this magic power of comparing pointers that no one else was allowed to do. And the core language people are adamant that we keep that, that pointers are not totally ordered. I mean, library people would love to have them always totally ordered. They're not totally ordered, except that they are, because you can use standard less to compare them. Yes. Okay. And I personally know and have not been able to find any platforms

where that's not true anymore. I mean, this all came initially from near pointers and far pointers kind of stuff. But these days, there's no C++ compiler that targets that. What about platforms that have read-only memory and read-write, you know what I'm trying to say, like Harvard architecture or something, right? I think I'm saying that right. Well, it's that, and as we move to things with GPUs and unified memory, I think we're still going to totally order these kinds of things.

Okay. You could have GPUs with separate memory spaces, but then you couldn't, say, put them all on the same set, because what would that mean? Right. So that's my personal opinion. Yeah, so far, you know, I'm trying to bring this. If you want to fight this on a committee, it's a huge battle.

Actually, that's the least of my concerns, is being able to total order pointers. Well, but, you know, least of my concerns, is being able to total order pointers. Well, but a simple question is, do I know if this pointer is in this array? And you can't portably write that. Well, you can portably write that code that's order n. You basically compare it with every element inside the array, the address of every element inside the array.

But you're allowed to compare void pointers, right? Or are you not allowed to? You can compare. I don't know if you can less than compare. If they're in the same object. Okay. The same array. If they're not in the same array, the compiler can do more than once.

Then you're back in undefined behavior or something. Yeah. All right. No platformers take advantage of that. If you look at standard less and standard less void, they pretty much call operator less than on pointers. Right, but they're allowed to.

Yes. And maybe one day static analyzers will actually catch this kind of thing. I don't know. Okay. Well, since we're talking about the committee a little bit, the next article is we have the pre-Belfast mailing, which is just a few weeks away. And there's a lot of papers here.

I haven't had a chance to go through all of them. I think we're under 200, which is a small amount. Yeah, that's true. Any highlights that either of you wanted to call out in the papers here? Well, I mean, so this meeting, so we have a ballot out for the C++20 standard. And this meeting, the primary purpose of the meeting is national body comments. So each country can make comments, and we have to answer those comments. Like they may want changes, they may want things removed.

And all the changes are to increase consensus among countries. So I think that's probably why there's less papers, because the national body comments are a little bit late. They haven't actually shown up yet, but they will. Okay. And that's primarily what the committee will be working on because we have to answer every one of them so we're not going to change anything right so none of these papers should be targeting c++ 20 only the the body comments should right well some of these papers are in like i have a paper um uh it? Oh, use size type instead of index type in span. But that's to address national body comment that I made. Okay.

It's just the paper that does all the actual changes. Wait, so you made a national body comment and then wrote a paper to address your own comment? Well, here's what the fix is. The comments are usually one or two lines. Sometimes you need a paper to be more than that. So I just did a search for constexpr because that's what I do. Are you going to expand the const of L and const in it? Well, I did it.

Actually, I did a search for const E. I think I did const actually originally too. Let's see. Um, Daveed has official, uh, as, as, as make a proposal for being able to do output debug tracing at constexpr time, which I'm kind of on board with. That would be nice. There's a lot of times it'd be really helpful, but I got to tell you when something goes wrong in constexpr and you're like, I have this test and it's not succeeding and I don't know why your only real option is to compile it, not in a constexpr context and use the debugger.

Yes, and that's about to get weird because we're adding is constant evaluated to see if you're in a constexpr context, which means you may have a different implementation for runtime versus constexpr time. Right. And how would you debug that, right? Because if you go into runtime mode you're running different code yeah carefully it's tough right these are yeah think about these things but it's you know how do you make this work right because you need to uh constexpr function

parameters that's i haven't read i saw that paper i haven't read through it yet david stone he did a talk on it i believe at cbpCon. I didn't get to the talk. But the idea is being able to specify that this function parameter must be a constant expression. So then inside the context of that function, you can use that parameter as if it were any other constant expression. You can use it in a compile time context and you can, you know, whatever, use it as a template parameter, whatever you want to do with it. It's weird because, I mean, I haven't read through the paper, but the idea I'm generally in favor of.

But a lot of people use constexpr as a poor man's optimization tool. It's like, well, it's compile time, so I'll just get to optimize. As if your optimizer didn't exist before. Right. No, no, no. Yeah. No, no, I need this.

This is driving some template parameter or some array size, or this is driving other things I need, you know, calculations, compile-time calculations. It goes both ways, though. I mean, there's certainly things like generating lookup tables, data sets, and whatever, where you say, I know that this is all available at compile time. Now please do it at compile time.

It's different than just saying as a poor man's optimizer, I think. Well, and you want to validate that, you know, this is done at compile time. I can write tests to make sure this table is correct. And then once I know it's correct, you know, I can just use it with reckless abandon. Right. One paper I wanted to call out here is Vittorio Romeo, who we had on like two, three months ago, did submit a paper for the Epochs proposal that he blogged about and talked about on our show. So I'll be interested to see how that's responded to at the committee. Have you taken a look at this or read his blog post, Nevin?

I did read through that. Yeah? I'm looking ahead at it. It's hard to tell. So one of the big committee things we have to decide is do we allow

things like an ABI break in C++ 23? Right. Because ABI is one of those shackles that a lot of

customers care about and a lot of customers don't. If you're somebody who can recompile all your code,

you don't care very much about ABI breaks. If you're someone who gets third-party libraries from somewhere, you care very much about ABI breaks. And the problem is if we can't break ABIs, we just keep adding things to the standard. We can't fix things.

For instance, one of the fears about concepts is that once you have a concept, you can't change it, an actual concrete concept. Because people are overloading based on it, and any changes you make to it can break somebody's code. Right. I mean, while the bar has been high for changing things in the standard, it's not been impossibly high. The canonical example I like to give is vector change in C++11. For 03 and before, the only way you could put elements into a vector is by copying, including if you default constructed an element,

you would default construct and then copy it into the vector. Right. In 11, that changed. It's actually a behavior change. You can notice it. You know, if you say, you know, I want three things that are default constructed, you get three separate default constructed things

instead of one thing that's been copied three times. Oh, interesting. Okay. So you can, you know, you can, it's very, you know, weird code to make it, take advantage of that, but you can write code that, you know, that's very weird code to take advantage of that, but you can write code that's a silent breakage. So it's not impossible to break things, it's just the bar is very, very high.

But for things like ABIs, there's weird stuff that you don't normally think about. Like one of the proposals we had for 17 was, instead of map using standard less as its comparator and set, we were going to use standard default order, which would default to standard less. And we thought, so the thing about standard less, and this is just one of my personal pet peeves, is that should it just call operator less than? Should you change it?

Should you change all six of less, greater, equal to? Should you change all six of those if you're changing one of them? And you can ask experts. And I don't mean experts in quotes. I mean, people you would consider real C++ experts and get very different answers on that question. And part of the problem was for things like set, the default ordering got conflated into standard less.

So we'd like to change that. So if people want to say specialize for complex, you don't have to specialize less, which makes no sense for complex. You can specialize default order. So the thought was, I think it was Alistair Meredith's proposal, and it got pretty far. I mean, I think it was in the working paper and taken out,

or very close to that. It was, okay, you have default order that becomes standard less, and it turns out if you're passing, like, a set or a map as a function, it changes the mangling, which makes it a VI break. But no one had thought about that for, you know, most of that proposal's life. Right. Another thing is emplace back changed in vector to now in 17 to return a reference to the element you emplaced.

Right. Pushback did not. Correct. Pushback was supposed to also change. And the reason it did not is that because since it's not a templated function, it could also be a breakage. Oh. I thought it wasn't changed just because there was less of a use case for it.

No, it had gotten brought up in Library Evolution that it should also be changed. And it was going to be. And at the very end, it's like, we can't change it because it's a concrete function. Huh. Okay, so when do we start breaking the things then, bringing it back to... That is one of the big discussions about C++23 is, you know, can we start breaking things? Can we break things? And how much breakage? What do you think? What do you think?

I think it's going to be a very contentious debate. I mean, we'd like to, right? People would like to, but, you know, there are real customers, you know, people who purchase contracts with GCC and other compilers that are going to say, no, you can't do this. Wow. For instance, Jonathan Wakely, who did the change of standard string. Standard string basically changed its implementation in C++11 to be no more copy on rate. Right. And it took to what? I think five or six years for him to finally get that in GCC.

Not because it was, it itself was technically difficult, but it's an ADI breakage for a whole bunch of things. Yeah. And we still kind of have a reference counted string in the standard, right? It's called standard runtime error. That has to be reference counted because you can't throw when you copy it. So that has to be a reference counted string. Oh. I learn all these things when I bring them up on a list

and go, no, you can't actually throw if you're trying to copy an exception, a standard exception. Right. I know of some people who, because they were using third-party libraries, couldn't upgrade their GCC for a long time because of that ABI break. It's interesting.

If I'm representing Argon, we recompile all our code, so ABI breaks don't affect us. I mean, if I'm representing Argon, I mean, you know, we recompile all our code, so, you know, ABI breaks don't affect us, other than we need to get things through the standard. Right. But, like, I've worked in places where, you know, I used to work at DRW in trading, and, you know, we get third-party libraries,

which wouldn't be supported, but we can't get an update to them. So whatever the library has is the ABI we have to live with. Yeah, I've never been in that situation myself. I've always basically relied on either standard libraries or open source libraries where I could recompile things if I needed to. I think on every C++ project I've ever worked on, actually. Kind of handy, I guess.

It's a nice freedom. It's a freedom you don't think about until you can actually take advantage of it. No, the first time I heard people talking about ABI, I'm like, what? I don't even understand until you can't actually take advantage of it. No, the first time I heard people talking about ABI, I'm like, what? Like, I don't even understand why this is a thing. Why are you talking about this right now? Like, yeah.

Well, and on the committee, it used to be kind of this, I don't want to say it was a secret, but we didn't, you know, ABI does not appear, or did not appear in the standard like anywhere, right? Yet we would have huge debates about it. That's been changing. There's like a library evolution standing document where we're saying that, yeah, ABI is important to us. So yeah, in the future, I mean, you know, I'd like us to be able to change some things.

You know, a lot of places we're putting ourselves in corners. I can give you one example, which I don't know if we can ever change this, but I'm working on small vector as proposal, which is a vector with embedded space, but then use an allocator. And wouldn't it be nice if we could just change regular vector to have a third parameter saying how much embedded space is here? Right. And that's a total ABI break, right? Another template parameter.

Right. And I've been thinking longer term, maybe if we can't break ABI's, maybe we should make all our class templates variatic, or as a default anyway, because that gives us room to make changes later. There's issues with that. Like I said, this is far flung.

It's not a problem. You're just starting to think about this. You're like, create standard vector of int comma, and then just add 43 things to it, because you can. And they don't actually do anything, because it's defined as a variadic template. It doesn't a good idea but it's an interesting point well like so one of the things um we kind of internally um meet a couple of the labs had a debate about um span right so span can't support fancy pointers right it has to be raw pointers right if it was variadic

we could have another template parameter eventually not not now, that would, say, be the pointer type. This is not neat, right? So in generic code, you would just say span of dot, dot, dot. Sure. But then you have to kind of define this. Okay, what are the generic functions versus what are the specific functions? What does it mean to be generic? You have some shape that you have in mind.

And like I said, I'm just starting to think about this. I don't have a proposal for this. Right. So before we move on from, oh, sorry. Nothing. There's really issues with it. I mean, it's, it's, it's not a slam dunk by any, by any means there's drawbacks. Right. I was going to say, before we move on from the paper mailings, there's at least a couple of things in here that are targeted for C++ 20 um fixing inconsistencies between const eval and constexpr from david stone which i did not have the time to fully get that and there's also if const eval by um barry revzin yeah and if const eval which is also in this in the same vein so i read a little bit of a debate about this one. So if const eval is meant to replace and or supplement the is constant evaluated trait, right?

Yes. Or is constant evaluated function or whatever that is. It is in the type traits header though, isn't it? I think it is. I think it is. Yeah. So a new syntax that would say if space constyvel space and then your condition or whatever. I don't know.

Do you have any opinion on these things? This is actually one on the committee reflectors, email reflectors. This is like a hot topic right now. I think the problem with using is constant evaluated, only kind of working in a constant evaluation context right now is kind of problematic. But we're very late in the process, right? Making changes to 20 is very difficult. Basically, Herb Sutter set out what the rules are for doing this, and we need very strong consensus.

In order for us to talk about this, evolution has to say, you know, take a vote on, should we even talk about this for C++20? And that requires a three-to-1 consensus before evolution can talk about it. If they approve the change, that also has to be 3-to-1 consensus, and then it has to go to plenary, which the same questions get asked, but need 4-to-1 consensus. So in plenary, it's like, you know, should we be talking about this for 20,

and if the answer's yes, you know, should we do this change? If the answer's still 4-to-1 yes, we can do it, because the bar should be high for 20, right? You know, I remember time you know i remember you know 98 came out and then nothing for a lot of years right oh three was kind of the bug fix for 98 and you know we heard about ox and then you know 2009 passed and it still wasn't out and then began the jokes of no no that's oa or ob yes and then i then i got involved with

standardization in 2010. And I was in Madrid and we shipped 11. And then the next meeting, we were thinking every six years we would ship a standard, which was Kona, I think. And then the meeting after that was Portland. We decided every three years we were going to ship a standard. And I think it's worked out well. I think ultimately every version of the standard has been better than the previous one. And I say that even though I know how the sausage is made.

But I think we keep coming up with a better language every time. And I think every three years is a good cadence to have. It's very easy to say, well, let's just slip for one meeting. The problem is as soon as you slip even for one feature, everyone goes, oh, wait, that's more time to get my other pet feature in. Right, yeah. And then you can go back to, what is it, 13 years between standards? It's so easy to do that, right?

If you say, we're not going to ship every three years, right? The grass is always greener on the other side. Yeah, if we slip, we can get more stuff in, and things will be better baked, and we've thought about them longer. That's true if we can stop ourselves from saying, yeah, okay, no more feature requests. But we know that's not true. Right. Yeah.

So for this whole if const eval, the question is, is this just a bug fix or is this an addition? Like, do you get rid of is constant evaluated? Because you don't actually, we don't know if you need it. Yeah, you don't know. Yeah, that was some of the debate I was reading. Yes. So if you're getting rid of that, then this is a bug fix. So in my opinion, this would be in scope for 20.

But if we're just adding if const eval, that's not just a bug fix. That's just a new feature, and that would not be in scope for 20. I wouldn't vote against it, but I wouldn't push very hard to try to get it. I personally think it is a bug fix, but that is not a universal opinion by any means. And yeah, the debate's been raging on for a couple of days on the email reflectors. I look forward to seeing how it turns out. Again, nobody's exactly

against doing this. It's the question is, can we do it now? Is really the question we're trying to answer. Because, you know, we don't like doing things at the last minute.

We've done a lot of things at the last minute. You know, deduction guides, for instance, you know, were kind of the last minute and the library,

like, tried to catch up to the last minute for 17. We're trying not to do that anymore. Even 11, like no except. The whole wide contract, narrow contract stuff from John Lacos, that showed up in Madrid. And before that, we were just kind of going through the standards saying,

yeah, that should be marked no except. This thing should not be marked no except. And that, like it or hate it, at least gave us a set of rules that we could just easily apply so we could move on and get things done. And I don't think we would have gotten nearly as good a no accept policy in the standard library in 11 had we not done that. I didn't realize that deduction guides, by the way, were a last-minute add. Yeah, and basically that was a very tough thing to get into the library.

The duty of taking them down is what changes have to happen to the library. A library isaries and core tend to usually last. For 20, there's a bunch of library things that were approved by Library Evolution that did not get in.

Any invocable is one of them. But there were a bunch of things that just, you know, library did not have time to go over the wording to make sure it gets in. I'm sure there's going to be

some national body comments on people going, well, I still want this feature in because it was approved. Okay. It's a bottleneck because basically it's the very last step. How do we not make this a bottleneck? We don't know right now. Yeah. Okay.

This next article we have real quick is an announcement for Meetup. It's not C++ related directly but anyone that is going to a c++ user group um should probably be aware of this they they did seem to change it before they made the first announcement earlier in this week but basically uh and jason i'm guessing are you the one who pays the fees for the meetup for the Denver user group? I am, yes. And it's something like $80 every six months or something like that for my meetup membership. Yeah, you said that for the Chicago one. I've been there.

I feel your pain. No. Well, I mean. I think it's a small price, really. Yeah, I mean, it seems like a fairly small price to run the meetup group. But they're changing it, and they claim it's to distribute the cost amongst the members. But the way they're describing it is they're reducing the fees for the organizer, but making members pay a $2 fee every time they go to an event, which really just sounds like an insane cash grab. It does. Do you see the note at the top, though?

They just updated this. Yeah, so they're saying that it's only for a small number of test groups that they're pushing in this change in November, right? Yeah, so I looked through, and I did not have an email from them saying that I was in one of these groups. But, of course, Twitter was going insane about this. I'm wondering if they, after seeing all the people talking about it on Twitter, if they are rethinking this policy. Because I think a lot of people are going to look for alternatives. Is this Meetup's policy? This is Meetup.com's policy.

Yeah, Meetup.com's policy. When you sign up for an event, pay $ bucks to go to your free user group meeting. And they say this will help increase engagement because people who pay are more likely to come, which is true. But then that $2 should be going to the meetup organizer, not to meetup.com. No. And also a lot of times if you're not sure you can go, you just don't pay. And if you don't know you can get in, you just won't go. Yeah. And the alternative is... We get in, you just won't go. Yeah.

And the alternative is. We have this problem in Chicago, right? You know, we get lots of signups, but there's no guarantee that we'll get even a fraction, you know, a large fraction of the number of people. Right, right. You know, there's times we've got, you know, we'll have 120 people sign up, you know,

which would have filled whatever room we got. And we were, you know, enough pizza for it. But it's an awful lot of spare pizza when, you know, only 40 or 50 people show up. And I don't know how to solve this problem. I don't think this solves this problem. Yeah. And what you're talking about right now, that's kind of the worst part about this. Cause if you want to keep your user group free to attend, then you can say, okay, well I'll foot the bill, the $2 for every member that comes. But if it's like what you're describing where a hundred people sign up, but only 40 actually show, you're still paying for the 100 members that signed up on meetup.com. And that's just

ridiculous. I actually have an interesting difference for my meetup, which I know is different from basically every other meetup on the planet. We expect somewhere between 95 and 101% turnout. That's awesome.'s awesome that's great yeah we can almost just count on it i think part of the advantage is that we're hosted at a company that has a considerable number of c++ developers so a lot of them just come if they're like oh yeah sure whatever why not i guess i'll go to the meetup tonight you know right the other problem chicago is and i'm sure number has it too right we occasionally have severe weather that's you know right the other problem chicago is and i'm sure denver has it too right we occasionally have severe weather that's you know well the meetup may not get canceled but it has been known to severely curtail participation and rightly so right you shouldn't be you know

trying to you know drive in dangerous conditions just get to yeah the only time actually we've had that happen in our three years was the day that uh herb sutter was coming to our meetup the roads were all open and it was safe to travel the next day, but it was a little bit slow going because there was some ice pack on the road still. Last thing I'll mention about this is I did see when the Twitter discussion was going on the other day that some people were talking about making their own open source competitor to meetup, and there did seem to be at least one that was already out there called Community with a K. So that one might be worth looking at

if you're looking for an alternative to Meetup if they do go forward with this policy. Yeah, I have like four tabs open with these things. Do you see any other alternatives? I don't know. A number of years ago we debated this in the Chicago C++ Users group, and it's how do you get the people there, right? Yeah.

That's ultimately why we stayed on Meetup and still stay on Meetup, is because people know where it is and people know where to go there. Yeah, if someone moves to Chicago, they can just go to meetup.com and see what user groups are around. And if you're new, that's where you're going to go. You're not going to go to

the more obscure places. Social media has this, right? That's why all the social media companies have a lot of strength in what they do, right? Because it's hard to leave because how do you get everybody else to leave with you? You know, I will say, though, since you mentioned that,

I guilted many people into coming into my meetup at CBPCon because I would ask in my talks, who goes to your local meetup? And then I would say, who lives in Denver? And I'd be like, seriously? Right. So I actually got like 10 new people coming last month, because they were had been one of my talks. Many people came up to me and said, I tried searching for the meetup, and I can't find it. And I'm like, you know what, meetup.com search engine is absolutely horrendous.

It never works. I'm like, what you need to do is search for the meetup name in Google and it will find the meetup.com page. Meetup.com search engine will never find it. And several people are like, oh yeah, you're right. There it is. I just found it using Google. So maybe, maybe the value in having all the people there already is not as big as we thought it was. Yeah. Yeah. It's weird because the whole reason I got involved was at the time I was looking for, is there a C++ meetup in Chicago? I heard about meetup.com. And I found somebody who was trying to start one.

I just put out a call for anybody who wanted to help start a C++ meetup. So I ended up becoming one of the founding members. But I haven't had to search for one since then because I know where it is. Okay. And then the last thing we have to mention is that uh c++ on c registration is open and uh the early bird tickets are almost gone right jason yeah when i just looked there was only like 34 available or something wow yeah no sorry 43 um i don't know how many there was in total, but it sounds like it's already selling pretty quickly. And is this going to be early next year, just like it was this year? Yeah, I don't think we've talked about the dates yet.

Yeah, we do. It's June. June. Oh, okay. So they pushed it back a little bit. Wasn't it in February or March this year? It was in February, which, as we all know, is a lovely time of year to visit South America. Yeah, June is going to be a lot nicer. Yeah, and it's in June and it's... We're in Prague for the standards meeting.

Yeah, yeah. I'm probably not going to make that one either. But this one is immediately after the standards meeting. Excuse me. In Bulgaria? Yes. June 7-10 will be C++ on C this year.

I wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high-quality code, as well as the methodology of static code analysis. In their blog, you'll find many articles on programming, code security, checks of open source projects, and much more. For example, they've recently posted an article which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly used static code analysis. Speaking of which, another recent article shows how to set up regular runs of the PVS Studio Static Code Analyzer on Travis CI. Links to these publications are in the show notes for this episode. Try PVS Studio.

The tool will help you find bugs and potential vulnerabilities in the code of programs written in C, C++, C Sharp, and Java. Well, Nevin, I know we mentioned a little bit in your bio, but do you want to tell us a little bit more about how you got started with C++? Sure. And that's right about, yeah, a friend of mine was working at Apple, and I knew from high school. And he gave me a call. One day he says, what do you know about C++? You guys invented it.

And I was very shy back then. I know it's hard to tell now. So it's like, well, I know nothing, so I want to find out about it. And I was working at Bell Labs in Illinois and like all the language stuff is Bell Labs, New Jersey at the time. So it's like, well,

I need to find someone and I'm looking around and okay, there's this guy in a different building and he's got a, he's got it on tape and I need to go to, you know, I want to go talk to him because I want to get it put on the machine that I can use. And that person's name is Jim Copleen. Um,

you know, famous book author, um, popularized the, that I can use. And that person's name is Jim Copleen. You know, famous C++ book author. Popularized the CRTP. Oh. And so I went over to his office, you know, met him. Wait, wait, I'm sorry. You said he had it on tape? Yes.

Now that I'm talking paper tape, or are we talking reel-to-reel? Reel-to-reel tape, yeah. Okie dokie. But yeah, so I go over to his you know i drive over to his office i mean the building's like you know a couple miles away and i end up in libra i want to learn c++ he goes cool and you know puts the tape on a machine and i start using it and eventually i have a question he can't answer so it's like well the inventor of the language works

at bell labs new jersey right you're in a straw straw again i'm still shy i was like okay i'll send him an email. And I spent like two days trying to get you out. I don't want to waste his time, right? I don't know him, right? It's kind of rock star status, right? So I spent two days writing an email. What the email was about was at the time,

if you did like four into I equals zero, the scope of the I was actually past the for loop. It would go to the other block. And I sent him an email asking him why it was like that. And he sent me a nice email back and told me why. It's like, yeah, basically couldn't break backwards capability at the time. Otherwise, he would have changed it. And I thought that was great.

And then I was leaving Bell Labs to work at Apple. And on my very last day, I actually got to meet Bjarne Strostrup. They flew him in. I was working on the 5DSS telephone switch, which at the time was one of the largest software projects in the world. The estimate at that time was there were 60 million lines of C code,

10 million of which were probably dead, but we didn't know it. They flew Bjarne in to give talks all day, and he was saying, yeah, just converting from C to C++ with function prototypes, which C did not have. That's the C++ invention. And C eventually got it.

Found three bugs. So just compiling with the C++ compiler, basically. Yeah, just compiling with it. And putting function prototypes in. Yeah, just found three bugs. So great. And at the time, I learned C++ at that time by looking at the output from Cfront.

Cfront's a C++, a C compiler. So I could figure out what happened behind the scenes because I could just see the code that was generated. I learned things like you could have lots of nested blocks inside of each other because that's the code Cfront. Every time you declare a variable, Cfront would have to generate C code that had a new block because in C, all variables

have to be declared at the beginning of the block. So I learned a lot about what C++ was doing. And then I worked at Apple, mainly on C stuff for a couple of years, and decided to go to, while I was there, decided to go to grad school. I went to the University of Arizona grad school.

And that's when kind of like, this is like mid-90s, and this is kind of when the exciting stuff in C++ was happening, but I didn't know it at the time. And like, I became, I was a TA, and I had to like teach a comparative, help teach a comparative programming languages course and there'd be C++ stuff and I had bugs

and I didn't know how to solve them. I would go through our library and try to find any articles at all on C++. There wasn't very much. But I managed to survive that and when I got out I worked at a startup called Pendragon Software Corporation in Chicago. Actually, Libertyville, which is Pendragon Software Corporation in Chicago. Actually, Libertyville, which is the town I live in now.

And I was working on Palm Pilot stuff, so I got to start doing C++ stuff again. And I got excited about it because I've always enjoyed it. And what I found is about that time, the STL was coming. And before then, C++ could be better than C or far, far worse than C. And there was kind of nothing really guiding us with how to write good C++ code. I think the STL is one of the first formalizations that showed us, yes, here's how you write better code. And so I did that, and eventually got a job at WMS Gaming

working on slot machines. And I worked there for like a decade. And since I was passionate about C++, people treated me as a C++ expert. But I was just kind of learning along with everybody else. But it was great because, you know, there were not people who could say, no, you shouldn't do that. We would just kind of figure out, like, what the right way to do things were. And it was great because, like, in a lot of ways, the C++ community is, for me, has been small because a lot of people who are, like, on the committee I've worked with before or met at conferences long before C++ conferences.

I worked with Sean Perrin at Apple, for instance. And I met Howard Hinnant at a conference called MacHack and Lisa Lippincott and John Kalb and Marshall Clow and a few others. So I've known these people as friends for decades. And so I worked at WMS Gaming for 10 years, and that's where Marshall Clow gave me a call in 2007 saying, Hey, we're doing this conference on Boost. You should come.

And I go, you're right. I should come. So I went to the first BoostCon and met Beeman Dawes, right, founder of Boost. And he goes, there's going to be a standards meeting in Chicago. Sorry, a standards meeting at Fermilab in three years. And I kind of give the joking answer. It's like, you know, I could have said, wait, wait, wait. I have a job.

I can fly somewhere earlier and just didn't think of that. But the real answer is it's kind of scary to go to a standards meeting, right? It's a bunch of book authors and experts. You kind of feel a little bit of an imposter syndrome. Why am I here? Everybody's so much smarter than me. And the first meeting kind of feels like that.

I didn't even know. The first meeting I went to was Fermilab in 2010. And I didn't even know I could vote in straw polls because no one had told me that. So I was still shy, so I'd kind of be in the middle of the room. I knew one other person there, so I would send him an email saying, hey, could you bring up this point? And he's trying to get me to say, you should just bring up that point. So the second meeting I go to is Madrid, and John Lagos is presenting narrow contracts and wide contracts.

And earlier in the week, he convinced me this was a good idea. And that whole thing is he wants to be able to throw through a no-accept clause in test harnessing. And during the plenary session for this, I'm thinking of this through, and I'm going, like, wait, wait, wait. If you have a preconditioned violation, you already hit undefined behavior, and the standard no longer applies. So why are we talking about this and I finally have enough nerve to bring this up during a very heated plenary discussion and I get quickly shot down

someone goes no except Trump's undefined behavior and I kind of slither back down I've been in a room full of very smart people and I'm kind of used to you say something other people pick up on it but it was just very contentious I still believe I'm right I think other people are coming to the realization

that I was right. And I'm no longer shy. I'm sure other members will tell you that. So that took the moment where you said, wait a minute, there's something I must say now. Yes. And this is logically inconsistent. This is not sound. Our arguments should be based on things that are sound. Right.

My own personal arguing, debating style is I don't like weak arguments for things. I only like strong arguments. Even weak arguments that support my position, I'm not a fan of. For instance, one of the big debates I got involved with was stream view

of no pointer value. Some people wanted stream view of no pointer value to be an empty stream view instead of undefined behavior. Right. And one of the arguments against this, and I'm against this, is I think both, you know, you pass string of null pointer and that's undefined behavior. String view should be the same thing.

An empty string is a different thing than a null pointer. You can conflate the two, and a lot of places do conflate the two, but they're not the same thing. I mean, I've done some database stuff. You know, it's, you know, is the data there versus is it empty? Right. And so one of the points someone else made was like, you know, this happens a lot during the debates. It's like, oh, we can't afford it because it's going to be a branch.

We can't afford a branch in StreamView. Although it gets optimized out most. And to me, that's a very weak argument against it. We always make that argument. If you want the feature, the cost is minor. Don't worry about it. And if you don't want the feature, every cycle counts. How dare you go to branch

it? And to me, those aren't good arguments. Even though it supports my position. But we should be making strong arguments, and we should acknowledge arguments that are on the opposite side. And yeah, so I got involved with this because Marshall Clow, who's chair of Library Working Group, couldn't

leave the room. And he's like, yeah, Nevin, you need to fight this. And I looked at him and go, you're right. But a lot of people want this. It's going to take more than just me. And I basically argued against changing stream view, against allowing no point of value. And I lost. And then I kind

of griped during our break. And other people go, no, no, Nevin, you're right. So we ended up having, I think it was rappers, but we had a big plenary session, you're right. I think it was rappers when we had a big plenary session. Right after the morning-morning plenary, we had a big session that basically, as Marshall called it, the Thunderdome. And convinced enough people that

no, it should not change. I'm willing to make those... If I feel strongly about something, I'm willing to do that. The other really strong thing I've done recently was Span's size function was signed deliberately. Yeah. So if you thought it should be that way, I'm sorry. So the problem with unsigned math is that it wraps legally. Right.

So if you have a sanitizer that's not supposed to have any false positives, you can't detect it. Because it cannot tell the difference between deliberately wrapping and accidentally wrapping. Okay. And most of the time, wrapping is accidental. And the other problem is because it's not undefined, it has to wrap, there's some optimizations that may not occur. Because the compiler also has to say, yeah, no, I got to make sure the math works. Right. So there was a thought in Span to change,

okay, this is a good time to make a change to make it sign instead of unsign. And Rob Douglas brought it to my attention, and it's like, no, the problem is interoperability, is that you end up having to cast all over the place if you're doing this. Right. And ultimately, you know,

and I'm not convinced, well, even if you're doing this. Right. And ultimately, you know, and I'm not convinced, well, even if you're convinced unsigned is the wrong type, is signed math the right type, or should we have a special type with special properties? We never actually explored that. Are we jumping into a different problem? I don't know the answer to that. You know, maybe we want undefined behavior.

Maybe we want check. Maybe we want, you know, okay, you can subtract, you know, negative one to, you know, max size minus one. I don't know what maybe we want undefined behavior, maybe we want check, maybe we want, you know, okay, you can, you know, negative one to, you know, max size minus one. I don't know what range we want or what range we want in the operations. And so, you know, my argument is we need to explore that if we want to actually make a change. And we have to solve interoperability. You know, we can't cast all over the place. People hate casting. And they cast in the wrong direction, right? Do you cast signed to unsigned or unsigned to signed types? No one knows. And there's problems if you do it wrong. And I had a bunch of examples

like, yeah, people cast and here's where they get it wrong. And again, it was another kind of Thunderdome session, right after Monday Morning Funary. It's like, whoever wanted to be there. And I was going against Vianna Stroshev and Herb Sutter. I mean, this is stressful. Don't get me wrong.

Much rather be on their side than against them. But I very strongly felt that I mean, you know, this is stressful. Don't get me wrong. Yeah. I'd much rather be on their side than against them. But, you know, I very strongly felt that this was, you know, we were making the wrong decision. And ultimately, it's now unsigned again.

Well, congratulations. Thanks. It's a tough battle. And it seems weird, right? These seem like little corner cases that we shouldn't care about. But the committee has to care about these

because people follow our lead. You know, the things we do are, do are what people model their stuff on. Containers are modeled almost exclusively on STL containers, 90% of the containers out there. So these details matter. We try to get them right as best we can. And it's not that the people opposite me are wrong, it's just based on our experiences

we're making different trade-offs. I can't just say they're wrong. They're not. They make very valid points. Unsigned math wrapping is problematic. So you've, well, it sounds like almost every job that you've had has been in a different industry. Yes. That's similar for me, actually.

I've constantly changed industries. Not very many people do that. What are you doing now at Argonne? At Argonne, I'm working on the Aurora project, which is the coming up fastest supercomputer in the world. We announced it a couple months ago. I'm working on a thing called Cocos for performance portability.

As new hardware comes out, we want to be able to... People want portable code, but they don't want to lose performance. These machines have lots of GPUs in them. And how do we do that as GPU architectures change over time? So Cocos is a framework developed at Sandia Labs. Carter and I initially did it.

Christian Trott is the current lead. And I'm working on a thing called Sickle backend for it. So there's different backends. There's like OpenMP, OpenMP Target, CUDA. And a new up-and-coming thing is SICKL from the Kronos group. We've also, Argon has joined the Kronos group, so we're involved with the SICKL standardization process as well. And this processor is made by Cray and Intel, and Intel has put, has said SICKL is the model we should be using. So we're working on a SICKL backend.

SICKL used to be based on OpenCL. We've recently changed. OpenCL is still very important to SICKL, but we're trying to be independent. And just as a backend so that, you know, as hardware changes, like, you know, people do a SICKL backend and then we just, on top of that, we just run, we just work. So the idea sounds like is to be able to take advantage of whatever hardware you have available. Yes, with portable code, without losing performance to do it. But it sounds like you'll probably also have to recompile.

Yes. Yeah, the labs generally, we can recompile it, you know. We can recompile at will. That's not a problem. And so Intel's working on DPC++, which is sickle backend. They also have a public version of public fork of LLVM. If you go to, what is it? I think Intel slash LLVM,

you can find their public version of sickle. And if somebody has time, we'd really actually like to get it in Compiler Explorer as well so people can play with it. Oh, well. It's usually doable. Submit a pull request for Matt and it'll get automatically built. Yeah. I think that

repository is public. The one that lists all of the compilers that get built nightly. I think you can submit your NPR. So Intel and CodePlay are the two doing implementations. CodePlay, they're figuring out how to make their license work with it. They want to, so it's getting the right people at CodePlay to make that happen.

This happens a lot with Compiler Explorer. They want to, so it's getting the right people at Coldplay to make that happen. Right. This happens a lot with, like, Compiler Explorer. So one of the advantages of being on the committee is, like, someone had asked, like, you know, hey, you know, can we get Intel's, I think Matt Gabel had asked, can we get Intel's compiler on the public site? Because we were both at DRW, and we had an internal version of Intel's compiler. Right. Could we put it publicly?

And, like, so I brought it up to an Intel committee member. It's like, okay, can we make this happen? It's like, probably. And they went and figured out the right lawyers to talk to to actually make it so we could do it. And same thing happened with EDG. Someone in the committee meeting said, can we get EDG's compiler on Compiler Explorer? And it's like, yeah, I'll talk to Matt. And Matt said, yeah, he'd like to do it.

And he talked to the people at EDG. It's like, yeah, we'd like to do it. And that stuff works. That's part of, you know, why. So one of the questions people, I know I'm kind of rambling, but, you know, one of the questions people ask is, why don't we have the committee meeting just, like, all over email, right? Or all electronic.

And it's like, I personally believe we have to make personal connections to get things, you know. That's probably true, but, you know. We get a lot of stuff. We do a lot of stuff over email. Don't get me wrong. We do. But I think ultimately we still have to meet face-to-face once in a while.

Darned human interaction. And the other thing about community meetings is that there's currently nine sessions going on in parallel, I think. My last time, which is insane. I mean, I've been double booked for presenting papers the last meeting like three times. Wow. But a lot of it is, you know, if Library Evolution has something that looks like, we don't know how the core language works or can we get a core language change,

we can walk over to that room and ask, you know, is this possible? And they can answer us quickly. You know, to try to do that over electronic communications, that doesn't tend to happen very quickly. Much more asynchronous. Well, I feel like we're running low in time. Is there anything you wanted to plug either for yourself or for Argon before we let you go, Nevin? No, just take a look at Cocos' public domain.

You can go to GitHub slash Cocos and find it and just check it out. It's pretty cool stuff. I mean, I think it's a good model for CPU, GPU programming. You know, and if I may, that's one of the main advantages to working with a national lab is almost everything that you do is public. Yes. one of the main advantages to working with a national lab is almost everything that you do is public yes which is i mean for those of us who like the open source world being paid to work on open source public domain whatever gpl stuff it's awesome oh it's absolutely awesome i mean it's it's it's probably it might be the first time i've been able to work on like things that are going on you know into the public oh wow directly congratulations like DRW, we could open source stuff,

but I don't want to say it was painful. It wasn't very painful. You just had to get lawyers to sign off on it. Right. When we were working on it, Matt Gobble and I did a version of Variant. It's kind of like what standard Variant is now. We never got around to it,

but we looked into open sourcing it, and they were fine with it. We wanted open sources so we could write a paper about it. At that time, it was right after Optional, and I decided that's just too much effort. We wanted open sourcing so we could write a paper about it. At that time it was right after optional and I decided that's just too much effort. We'll never get variant in the standard in like three years. What did I know? Yeah, what did you know?

Okay, well it's been great having you on the show today, Nevin. Great to be here. I've enjoyed this. I love doing this kind of thing. I like spreading the word. You guys do a great job spreading the word. Thanks. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in,

or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Facebook and follow CppCast on Twitter. You can also follow me at Rob W Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash CppCast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by

podcastthemes.com.