CppCast - Postmodern C++

Episode Date: June 8, 2017

Rob and Jason are joined by Tony Van Eerd to talk about his recent award winning C++Now talk on Postmodern C++ and his views on lock-free programming. Tony Van Eerd has been coding for well over 25 years, and hopefully coding well for some of that. Mostly in graphics/video/film/broadcast (at Inscriber & Adobe), writing low level pixel++, high level UI, threading, and everything else. He now enables painting with light at Christie Digital. He is on the C++ Committee. He is a Ninja and a Jedi. News C++ News Sources: /r/cpp C++ Enthusiasts Meeting C++ Blogroll IsoCpp Announcing C++Now 2018 C++Now 2017 Playlist C++ Coding Guidelines (Howard Hinnant) Why I Put const On The Right Speakers announced for pacific++ Tony Van Eerd @tvaneerd Tony Van Eerd's GitHub Links Christie Digital Christie Digital Projection Mapping Videos C++Now 2017: Tony Van Eerd "Postmodern C++" Sponsors Backtrace Hosts @robwirving @lefticus Better C++/Chicago

This episode of CppCast is sponsored by JFrog, the universal artifact repository, including C++ binaries thanks to the integration of Conan, C, and C++ Package Manager. Start today at jfrog.com and conan.io. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket now or submit a talk. The deadline to get in a submission is June 11th. Episode 104 of CppCast with guest Tony Van Eerd, recorded June 7th, 2017. In this episode, we talk about coding guidelines and where to put const. Then we talk to Tony Van Eerd from Christie Digital. Tony talks to us about his recent postmodern C++ talk and C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner.

Jason, how are you doing today? Doing good, Rob. How are you doing? Doing good. Weather's starting to be pretty nice here. You know, nice and warm. How about you? We are kind of teetering on the happy point of 60s to 70s, which is where we prefer it, and then 70s, 80s, 90s are in the forecast. That's unnecessary. It wasn't too long ago. You were still getting some random snow, right?

Yeah, we got snow down here in Denver during C++ Now, which is crazy late in late May. That's pretty late. Yeah. Well, at the top of our episode, I'd like to read a piece of feedback. This week, we got a comment from Tom on the website from last episode. And he writes in, I found your podcast a few weeks ago, i'm addicted great work i have a question for you when you go through news frequently you mention articles that c++ developers should read as i am new and still learning the language i don't know all the good websites where you can get news about c++ could you please provide a few where you think developers

should check each day with their morning coffee yeah so uh we get our news primarily from reddit you know cpp subreddit it's pretty active there i also subscribe to uh the facebook group c++ enthusiasts and there's a linkedin uh c++ developers group and twitter if you follow meeting c++ yeah yeah on twitter you'll get all the news also yeah and jens from meeting c++ has like a weekly blog role i believe or he writes uh new c++ blog articles yeah that's got a lot of detail in it. And we've got the Slack channel, of course. You can get lots of news there. But that's not so much morning coffee kind of thing. Yeah, it's just like an ongoing discussion.

Yeah. But yeah, plenty of places. We'll put a couple links in the show notes for where you can go to get news. ISOcpp.org? Yes, that's another good one. Obviously, ISOcpp.org. You can get thatS-O-C-P-P dot org. You can get that one in your RSS feed also. Oh, yeah.

And we love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email at feedback at cpgas.com. And don't forget to leave us a review on iTunes. Joining us today is Tony Van Eerd. Tony has been coding for well over 25 years and hopefully coding well for some of that, mostly in graphics, video, film, broadcast, Inscriber, and Adobe, writing low-level Pixel++, high-level UI, threading, and everything else. He now enables painting with light at Christie Digital. He's on the C++ community, and he is a ninja and a Jedi. Tony, welcome to the show. Hey, nice to be here. How do you officially get recognized as a Jedi?

You convince your kids when they're really young that you're a Jedi, and you do things like when something's going to happen, and you know, when you have really young kids, you're like, oh, that's going to get knocked off the table, right? Or whatever, or someone's going to get hurt. You can just see it's going to happen. So you tell them, hey, that's going to fall off the table. And then it does. And you say, you know, as a Jedi, you can use the Force to see into the future a little bit. And you just go from there.

I can see Rob doing this. There's also a Jedi religion, right? So you could just be part of the Jedi religion and put that on your census and whatnot. Yeah, that's true. It was a big thing in England for a while there. There was a lot of people putting Jedi on as their religion. I know you can go to classes and stuff and learn lightsaber combat.

Some people get really into the whole jedi as a religion thing we actually had uh when my kids were like eight or around that age whatever and they had their like fake lightsabers and all this stuff we started a uh we started doing ninja training for their friends in the basement and stuff. And the best part was Ninja, I can't remember if it was Ninja or Jedi training or both, but that training never ends. So if we see one of these kids who are teenagers now, like you're just driving down the road or something, you're just allowed to throw something at them and say, you know,

you hit them in the head like, Ninja training, you should have been ready for that. It's like you signed up when you were eight. That's great. I might have to do that. Okay. Well, Tony, we got a couple of news articles to read through. Feel free to comment on any of these and then we'll start talking about postmodern C++. Okay, yeah, whatever that is. Okay, so the first one we have here is from C++ Now. First, they're announcing C++ Now 2018, which is going to be May 6th to 11th, still in Aspen, Colorado. And they also announced the winners, Best S best session, best presentation, most educational, most inspiring, most engaging and best lightning talk. And we have, uh, two of the winners from those presentations on the show right now. Congratulations to Jason and Tony. True. Yeah.

Tony. So you won two of these awards, most inspiring and most engaging. Yeah. I don't know how that happened i'm actually what the part that that you know bothers me most is i didn't win best presentation some boring presentation on constexpr one like how like constexpr is by definition boring because it's not dynamic right it all happens at static time it's it's like it's like premature computation you you run and it's already done right i don't know who oh wait whose talk was that yeah i i can't remember either yeah okay sorry good stuff um and and the other thing to mention is that the c++ now videos are all now online and

i'll put a link to that playlist in the show notes. So if you didn't make it to C++ now, you can now watch all of that great content online. It is the best conference. I say that every year, and every year I agree with myself from the previous year that it is my favorite conference. And you should go online and watch the videos but that is only half the conference you really got to show up and so much stuff happens between the talks because it's a small conference so you get to talk to everybody you know things happen there yeah and an interesting like i i totally agree like this conference the the point of is that you have to be there you have to be involved in the talks. You have to be in the room.

But the people recording only had one microphone for Ben and I to share. And so that one microphone was actually ended up taped to the podium, even though it was a lapel mic. So it picked up both of our voices and for our talk, it actually managed to pick up some of the audience interaction, which I was very impressed by. Yeah. So like,

let's just do it that way. I said that every year, let's get a, let's get a parabolic mic or something pointed at the audience and, and capture some of that interaction. The other thing about that conference is, yeah. The other thing about that conference that I always think about is you go to any other C++ conference and they'll present the latest, greatest ideas.

But it's like, where did that idea come from? It came from C++ Now. So many times, the origination of that idea was a discussion at C++ Now. And that's where it started. That's where it percolated. And a year or two later, you see it as a mainstream thing. It started at C++ Now in between the talks. Okay, so the next article we have was just posted on Reddit,

but I think it's an older post. It's from Howard Hinnant's C++ Coding Guidelines. And it's interesting because you hear coding guidelines and you expect to see lots of rules and things about syntax, but this is really short. He prioritizes what he thinks are most important when writing C++ code in order. That's correctness, runtime performance, compile time performance, maintainability, and ease to write. And then he just talks about measuring your code and testing. So it's a very concise bit of coding guidelines,

but I don't think anyone can disagree with anything he's saying here. Right. And that's why we use constexpr, because that eliminates runtime issues. Yeah. It's funny that 90% of his coding guidelines aren't even C++. It's just coding guidelines, right? And I don't know. Is Howard ever wrong about anything?

So follow his guidelines. Yeah. And then the next article we have is why I put const on the right. And this is about the rules for const where it can be applied to either the left or right-hand side of a symbol. I've always kind of defaulted to putting it on the left. But after reading this article, I think I might be willing to change. This may have convinced me. Changed. I'll convince you.

Just do it. It's not even an article anymore to me. I've been doing it that way for 10 years. As soon as you run into a situation where you need a pointer to a pointer and you need a const pointer to a non-const pointer or strange combinations, it's hard. Suddenly it gets really hard and you just put it on the right. I mean, you can use type defs to simplify your life as well, but I just start putting it on the right. I don't know anyone who's switched to putting it on the right and then switched back. So there's

a sign for you. If you switch here, you will never go back. One of those, one of those one of those things my main argument for keeping it on the left which i still do is often if you get a compiler error because your const and non-const doesn't match up the compiler error will actually have it on the left so i want the compiler error to match what my code is actually showing instead of the rearranged thing. I used to be able to show examples for all three major compilers of them rearranging it from int const to const int, but I get the suspicion that Clang has been reformatting their errors lately because I'm having a harder time getting it to rearrange that const on me. Yeah, what you're really saying is we need to fix the compilers.

We also need to fix the standard. It comes up every now and then that the standard uses const on the left. And at least it's consistent. It does it everywhere. And there's a bunch of people, every time there's a new proposal, we're like, can we just put it on the right now? Can we start switching? It's like, no. You either switch the whole standard or you can't just, oh, these new parts are on the right. Although that would let people know that either one works, but no sense being confusing. It would be kind of curious to see just how big the proposal would be to correct or change every single example. Tony, you're – member of the Starens Committee.

What's the reasoning that goes into something like this where a new keyword is added and it's allowed to be on either left or right side? I mean, what's kind of the thought process into that? Well, I think for anything new, we try to avoid that okay i think i think a lot of stuff is just baggage right that we've gotten from the early days or from c or something like that now i i think there's a tendency to be let's not be and let's like there's no sense adding more ambiguity there's enough already so but i think sometimes it still happens because you also want to – if you were to add another like pure or some kind of thing that was like constant, like volatile,

you would say, well, just follow the same rule, right? So you would – you just put it in the same bucket as something else. And then if that bucket already has weird cases, you've just added another word to the weird case bucket. But that's still easier than, at least it stays consistent with what you already have. Consistency is always a big thing, right? Right. That makes sense.

Okay. And then the last article I wanted to mention was we now have all the speakers announced for Pacific++. And we already knew that Jason, you, and Chandler would be doing keynotes. But now we know who all the other speakers at that conference will be, including one of our previous guests, Matt Bentley. Yes. Yeah, it looks like it should be a good lineup, I think. Yeah, I'm not too familiar with some of these other speakers.

They're all in New Zealand and Australia, but I'm sure it'll be a great conference. Yeah, I'm kind of jealous. I would like to be going there. I mean, I would just like to go to New Zealand anyhow, but it would be kind of cool to go to that conference. Well, tickets are still for sale. You can go, Tony. Yeah, I have this problem of how many C++ things I go to a year. I'm already pushing my limits. But maybe next, I'll have to plan ahead. I try to do, I end up doing four or five a year,

which for, I'm supposed to be writing code and getting work done. It's a lot. Yes, yeah, I mean, I'm supposed to be writing code and getting work done. It's a lot. Yes. Yeah. I mean, I'm self-employed and five years, a lot to try to prepare for. Certainly.

Yeah. If you're listening to the show on the day it airs, June 9th, and that today is the last day that you can get the early bird price on the Pacific plus plus conference tickets. Yes. So make sure you buy your tickets as soon as possible. Buy now, we'll throw in free

C++ Now videos on YouTube. Something, something, I don't know. You know, I can sweeten the pot and also offer my C++ weekly videos on YouTube for free. There you go. No Ginsu knives, but we will give you videos. All right.

Okay, Tony. So let's start talking about your presentation from C++ Now. As we already mentioned, it won the most inspiring and most engaging awards. So what exactly is this concept of postmodern C++? I'm not sure we answered that question in the whole talk. It was a question that came up on Twitter with Jens and meeting C++. He had some conversation with people about what does modern C++ mean? Because it turns out modern C++ has been around for like 20 years now. Yeah. So we're starting to wonder, are we still writing modern C++ mean? Because it turns out modern C++ has been around for like 20 years now.

Yeah. So we're starting to wonder, are we still writing modern C++? Or is that old and now this new stuff is someone's like, well, we'll just call it more modern. And that, you know, obviously the right answer is postmodern. We're in the postmodern C++ era. And actually after the talk, I was talking michael case or i don't know if that's how you pronounce his name but everyone knows who i'm talking about um we actually are

in the post-modern era of post-modernism has this idea of everything's kind of relative and my point of view is just as good as your point of view. And you could kind of translate that into the multi-paradigm that is C++, right? What is right for me might not be right for you, but it's right for this situation. And you see that in our coding styles a lot more now that postmodern C++ is not just one style of programming. It's multiple styles of programming. This part of my code is functional. This part of my code is object-oriented, whatever. That's postmodern C++. I didn't talk about any of that, actually, though, in my talk. That would be my answer for what is postmodern C++.

But instead, my talk was basically one giant long joke, is what the whole point of that talk was about applying postmodernism, whichever that means. And I'm not sure I know what it means, but apply that to C++. And I think it ended up, I guess, had some insight in it because people I can see why people thought it was engaging because I purposely tried to be funny kind of thing. But it seemed I guess it was inspiring. So I guess there was some actual content in there that people read content out of it, whether there was content or not. Well, did you get any feedback from anyone specifically saying what they did

or didn't like about the talk? Like what resonated with them? Yeah, it's kind of funny because I had, because it really was, some point along the way, I decided that the talk itself must be postmodern, whatever also that means. So the talk itself was, I was trying to talk on multiple levels at different times. And there was, you know, you could look at the talk at this level or at a meta level. The talk itself was, if I was showing something in slides, I might have also been doing it.

And I explained some of that in the talk. And I had one guy who was like, you shouldn't have explained that. That was the funny part, was that you were doing what you were saying. And if you explain the joke, it's not funny anymore. And I'm like, yeah, but I think everyone else just missed that part completely. So you kind of have to explain some stuff. But I kind of think that different people, it's a bit of a shotgun talk where it's just like a lot of little ideas, which hopefully kind of had a theme at the end. But I think different people got different pieces out of it, right? And so it's like, if you just got one thing,

and that's the other postmodernism, right? You got something different out of it from the other guy, that's okay. Well, so then on that topic, the one thing that really stuck with me that I remember from being there at the talk live was this idea that you don't stick to strict code formatting rules. Jason, we lost you for a moment. So the thing that stuck with me from the talk was that you don't stick to strict code formatting rules.

Is that right? Yeah. You know, I've been tempted to do a talk someday because I have this tendency to do avant-garde talks at cpp now it is the conference for doing things out of the box uh one day i'd like to do a talk just on religious coding right like just the the various like let's talk vi versus emacs right and and actually try to come to conclusion or something like that so i'm like it was a little taste of that. It's like, let's talk about formatting. Where do you put your brackets?

Speaking, like we were talking about coding guidelines. When I was at BlackBerry, BlackBerry was doing Java stuff and then they switched back to C++ and they looked around. They're like, hey, Tony, you know C++. Make up the guidelines. First thing they said was was can you give us a safe subset of c++ and tell people to use that and i was like uh no nope can't can't do that there's like and i guess that's what some of the coding guidelines are trying to do now is like

here's how you use c++ safely but you can't really call it a subset you know there's some patterns you can do but really if if we're if you're going to c++ you got to commit to it right but um they're like make up a coding guideline and so i was stupid and and decided well you know we had these coding guidelines in java and we had this coding guideline in this group over here and everyone and so i tried to make a coding guideline that was kind of no one would complain about it's like okay put your brackets here because this is the way we used to do it and all this stuff and i should have just said do it exactly like my code here is my coding guideline

like 100 i cannot code incorrectly because it's my guideline right and and that was like that's like my worst mistake in my career i could have just never had a coding guideline complaint myself anymore because it's just mine and every argument would be solved by i'm right um but somewhere along the way i gave up on like i guess once you've looked at enough code from different teams and i i did i have a tendency to do a lot of code reviews across teams and stuff like that i don't care care where you put your brackets anymore because, well, one, it's all valid. If it compiles, it's valid. And Fabio Fricassi, I think his name is, he one time at one of the committee meetings was saying that he puts for small if statements, he puts his brackets, you know, the bracket goes at the end of the if and

for bigger if statements, the bracket goes on its own line. And I was like, no, you must choose a religion. You can't live in between the religions. And then I was like, wait a second, that makes a lot of sense. So that's, I now do this where I change my bracketing or whatever kind of formatting to be, it, you, you knew, and this is sort of the point of my talk is coding is hard for various reasons, but one of the hardest things in coding is communicating to your other programmers. So you're very limited, like Twitter is limited to how much you can say in code. You're limited to what's in, like you have to, it has to compile. So you're, you can't just write whatever you want. You've got comments, but no one looks at them. So formatting is one of the

ways you can communicate to your fellow programmer. So I now use curly brackets one way, if it's a small if statement and I want it to be like, hey, this is unimportant. It's just checking the input params. You know, the real code is in over here. But then if it's a big, you know, the main for loop, the main if statement, something like that. Okay, that gets its own lines. I don't know. It just separates code better.

And same with like how do you format a case statement once if it's all single line case statements, put them all on a single line. It suddenly looks like a table. So I don't really like code formatting tools because they tend to, unless you can get one that's, like, really smart and has an artistic aesthetic to itself and says, oh, yeah, that's good looking, you know, bracketing. I really like that bracketing. But I also don't expect anyone to have like 18 bracket styles in one file. I used to work at Adobe, and we ended up switching to have encoding style. But at one point we didn't, and I could tell who wrote code based on looking at the format of the code. It's like, ah, Bob wrote this code because, you know, it just looks like Bob's code, right?

There's actually value in that somehow. It gives you a, you know, a mindset of, ah, this is what I should be thinking now. Yeah, I've given up. Anywhere you would draw the line where you say, well, this code is so poorly formatted, it's just unreadable and I need to have a talk with this guy. Yeah, I think so. I do think there's only two or three religions, so stick to them.

Basically, people who indent their curly brackets, you've gone too far. That's the limit. I don't need that much vertical white space. Horizontal, yeah. So I haven't had a chance to watch the talk yet but um what was your favorite part of the talk uh or most important part of the talk from your point of view um well one i i will uh tell people to go watch the talk but uh i watched the talk last night because it just came out which is cringing. Like, I don't like watching my own talks.

Oh, yeah, it's horrible. Like, it's just weird, right? Yeah. And I'm going to say it doesn't translate. It's one of those, you know, you had to be there kind of things. But go watch it anyhow. But there's one part where I use, you know, 180-point font to get a point across. So I guess that's one of my things. And it's about using functions. I spent a lot of time, like I said, doing code reviews. And for years, I've been trying to figure out like, how do I get people to code in ways that I think would be

better? You know, and not that I'm not sitting in a sea of bad code. The guys around me right now are really good programmers and everything. But you always, you see something, you're like, wait a second, this could be done better. And you hear a lot of people say, well, like, use object-oriented or use this or use that. Here's all these things that will help make your code better. Sure, those will help. The number one thing, I i think is write a function like there is too much like when you see uh functions that are a couple few like 500 lines long thousand line long and ten thousand line functions break that up and i think that is

the same as if you were uh in english class in high school it's like hey that's a new paragraph you have there separate your ideas into separate paragraphs and don't have run-on sentences. It's the exact same thing in coding. If you can take that block, when I see a block of code that says step one and it's got 20 lines of code and then it says step two and there's 20 lines,

it's like, hey, why don't you make a function called step one? I don't even care if you don't give it a great name. Call it step one for now. Because you just see a C of code and I can't understand what's going on when you're writing, it made sense. But when I'm reviewing it afterwards, it's hard to follow. Right. And I think, I think it can't, I mean, we talked about this. Chandler had a good point during the talk that when you're coding something, you've got all these things in your head, right? You've got this data in your head. You kind of know what it is, you kind of know where you want to go,

and you just want to get it all down on paper because it's a lot. It's a complicated problem, so you've got a lot of things floating around your head. So you don't want to stop and think about breaking up functions, but you just want to write it out. And it's like, yeah, I understand that. But at the same time, if you can take portions of that and separate it into a function, then it doesn't have to be in your head anymore. You can just be like, ah, this is the step where I convert my 3D points to 2D points and blah, blah, blah. I do projection mapping and stuff. We do a lot of 2D to 3D and back and forth. As soon as you make a function that does that task for you, you drop it out of your brain.

You're like, that's done. I don't have to worry about it anymore. You get a secondary problem of if you're trying to debug some code, then you don't know where the bug is and you have to look everywhere. So you find yourself diving into functions, diving out of functions to see, is it in this function? Is this where I have to go? So it can get too much. You can get too many levels of functions and you can't find the code but overall i think the number one problem in in code right now is hey you should have wrote a function so i spent at

least five or ten minutes of my talk sarcastically uh showing the um paper from david wheeler that introduced subroutines in the 1950s, as if that was like, this is brand new technology, because it must be brand new technology, because I don't see it in my code base. So I actually found that very interesting, because I didn't even, I never stopped to think that there was a point when subroutines were created, when they were invented. Yeah, yeah. I am not that old. As I said in my Twitter when I first tweeted all this stuff,

I hope it catches on. I hope the concept of subroutine really catches on and we start using it. Do you have any comments for anyone who might be concerned that while adding all these extra function calls is going to slow down my code? My comment is, yeah. I mean, the answer for that is always measure, right? Right. Someone is talking about, and let's go back to Howard's coding guidelines.

It's in there, right? You don't know how fast or slow something is. And we all think we do. We all have our instincts for, we've done this before. We know this is slow. We know this is fast. And sure, you know that N squared is slower than N log N or something, unless one is localized in memory and the other is not right but you don't really know unless you measure it and uh i actually howard actually had

i don't know if it was somewhere on the committee or where i was reading it or or on stack overflow or someplace he had a case where he thought something was going to be you know a performance penalty or not and he measured it he got an answer not what he expected and i'm like well if howard's not sure about whether something is performant or not and he has to measure we all have to measure like right and in the case of specific case of like all these function calls are going to slow me down no no they're not i're not. I mean, you make it in line if you have to or whatever, but the chances of a function call overhead is your problem is so low. You're, you're waiting for memory. That's, that's what you're, if your code is slow, it's because you're

waiting for memory is nine times out of 10. I think someone in the session suggested the possibility that if you didn't think, you know think this block of code was worth a full function, that you could just make a quick inline lambda to at least give you some logical separation. What do you think of that? Yeah, I've noticed we're doing that in our code. I've done that. And I didn't think it up. I was looking at our code base and saw other people doing it. I was like, huh, this is kind of interesting. So I'm still toying with it. I think it's kind of worthwhile.

It's weird because, and this is a question I ask people, I love to ask, I don't like to be mean to interns and students when they come to interviews, But I do like to ask questions like, how many times do you need to see a piece of code, like duplicated before you would put it into a function? And now I'm going to give away the answer. But everyone says two, three, you know, I've seen this code three times, I'm going to put it into a function. And the answer is one. Right? I don't need to see it more than once. It's a block of code. Put it in a function. But as soon as you put it in a function, people then think, oh, this is going to be reused. I'm going to have to put some extra effort into it to make it a reusable function. And maybe I have to

document and all this kind of stuff. And it's like, well, that would be good. But I don't care if this function is reused or not. It's still worthwhile to just put it in a function to separate your code. And that lambda, making it a lambda inside your bigger function is kind of a halfway step to that. It's like, look, I'm going to separate this, but it's not reusable. It is kind of specific, and I don't want to put the extra effort into making it reusable. I'm just going to put it into a lambda so it's separate. And then you might, one of the advantages of that is you might have two or three kind of local variables inside that Lambda

that are now not spilling out into the rest of the function anymore. They really start and end in that Lambda and you don't have to be concerned as what do those variables do later on. They don't exist later on. I mean, you can do that just with curly brackets as well.

And I've seen people do that as well, where they just put curly brackets around a block of code, not because there's an if at the top or anything, just, hey, this is a block of code. And these variables I'm going to put in this curly bracket, they're only needed for the next 10 lines. That's kind of cool. But like, yeah, why not go one more step, put it in a lambda, then you also get a name for that block of code right um and so actually name it don't just call it function or fn i've seen i've seen that just oh i just called my lambda f it's like well you know you had an opportunity there um it was also mentioned uh

by uh peter summer summer whatever man i'm bad with names summer lad summer fields summer i know i'm summerland there you go i know him really well but like i picture him in my head but i'm i when i read when i read like harry potter and i'm done reading harry potter and someone says what'd you think of uh you know that ron ron character i'm like which one was that like ron he's one of the main i'm like oh yeah the a name that started with R and had some other letters. Like, I just skip over it. It's just a shape. I just see the shape.

I don't see the letters. Anyhow, Peter brought up that if you make it a lambda, you can't unit test that lambda because it's inside that function. You can't, you you know get it so that that that comes to the line of uh the answer to every c++ question is it depends even that's what i should have said for the last thing about you know do do function call overhead should i be worried about that it depends right so should i make these functions local lambdas? It depends. I would say that's better than not doing that. It's better than having one giant function.

But once you put it in a lambda, well, maybe it would be worthwhile to make it a separate function because then I can test it as an individual function. But I'm actually now thinking, I didn't say that at the time of the talk, but a lambda is better than not than just leaving it as a 10 000 line function right like that one i'm just gonna i'm just it doesn't even depend it's just no the lambda is better there's there's no question there there's a an interesting well to me interesting point that didn't come up in the talk when you're talking about these grotesquely large functions where i've seen the optimizer actually throw up its hands once a function gets to a certain length.

Yeah. And your code, like it's the actual generated code quality starts to degrade quickly once the optimizer can no longer figure out what you're doing with your local variables. Yeah, it probably just turns into as if it was debug, right? Just like, okay, I'm just going to do this, you know, debug right just like okay i'm just gonna do this you know the one for one i mean i'm just gonna do what exactly what you said instead of thinking

about it yeah we had a case back in the day it's been several years ago so both the code has been cleaned up and clang has improved since then but we could not compile the code and release mode in clang because we simply did not have a machine with enough RAM for the optimizer. Does anyone remember Wattcom? Yes. Wattcom compiler? Yes. And that thing would just spend all day.

If you gave it time and memory, it would just keep going. Just, I'm going to keep optimizing this. And then it would always end with out of memory. Like, it would say, I could only go this far with my optimizer because I've used up all your memory. And okay, I'm going to stop. That's as best as I could do. Like it wouldn't fail.

It would just put a message saying, I'm done optimizing because you didn't give me enough memory. So it'll be like, I did a hundred passes. I'm done. I give up now or something. Yeah, yeah. It's like, this is the best I can do because you didn't give me a beefy machine. I'm like, I give up now or something. Yeah, yeah. It's like, this is the best I can do because you didn't give me

a beefy machine. I'm like, is there any limit? It's like, no, there was never a limit that I would say, I've done all I can. It's like, I will keep doing more if you give me more resources. That's pretty crazy. Yeah. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors.

JFrog is the leading DevOps solution provider that gives engineers the freedom of choice. Manage and securely host your packages for any programming language with Artifactory. With highly available registries based on-prem or in the cloud, and integrations with all major build and continuous integration

tools, Artifactory provides the only universal, automated, end-to-end solution from development to production. Artifactory and Bintray now provide full support for Conan's C and C++ Package Manager, the free open-source tool for developers that works in any OS or platform and integrates with all build systems, providing the best support for binary package creation and reuse across platforms. Validated in the field to provide a flexible, production-ready solution, and with a growing community,

Conan is the leading multi-platform C++ package manager together, JFrog and Conan provide an effective, modern and powerful solution for DevOps for the C++ ecosystem. If you want to learn more, go to jfrog.com and conan.io. So you've also given many talks on lock free programming. What makes lock free so interesting to you? That is a weird hobby.

That's what lock-free is. One of the things I like about it is that it's actually, I mean, it's a hard problem, so it's challenging. I like that. But it actually tends to be problems that fit into your head. You don't have to have a whiteboard. You don't have to write anything down. This is the way I do it. And people, when I tell that to people, they're always like, that's insane. How do you work on this without a whiteboard or anything? But a lock-free problem most likely only has two or three variables in it. If you have some lock-free

thing that has eight variables, you're screwed, right? Like there's no way you can get that correct. So lock-free problems by definition are small. So I can, especially when my kids were younger, you know, you're always picking them up, dropping them off, doing this and that, and you're waiting in the car or something. I'd be like, oh, I've got 10 minutes. I'm going to work on that lock-free problem in my head. I'll just sit and stare out in space and people are like, what are you doing? I'm doing work. So I don't know.

And they are – it's a very pure problem, right? It is very small, pure, and interesting problems. And when I started talking about it, hardly anybody was. So it was, somehow I just thought, yeah, this is something that people are talking about, but no one's giving talks on. So there was a lot of misinformation out there. And I was like, this is bad because everyone's doing it wrong. So i should get out there and talk about it so that's what happened i should i should i can tell you that um where it all started from someone just asked me this like two days ago um i was at adobe and we had our own critical section class that was

uh you know because this is the day before standard mutex um and our critical section class because it's based on windows critical section has to call init critical section in its constructor okay fine so then i noticed there was a function that had a critical section inside of it and the critical section has to be static so it lasts beyond the function it wasn't like in a class or anything it was just a static critical section but the static critical section is inside the function instead of being global outside the function, which means it gets emitted first time the function is called, which you think, well, what if two threads are calling this function?

Do you think two threads are calling this function? Well, yes, they're using a critical section. So obviously they expect two threads to call this function. And once the critical section is emitted, everything's going to be great. But there's a race on the initialization of the critical section. And that's all solved now in C++ 11 and forward. But at the time, I was like,

this code is obviously broken. It's got the critical section itself is not safe. So I had to dig into how do you solve that problem? How do I initialize something where in the constructor, how do you check for, hey, is the constructor being called from another thread at the same time? Which should never happen, but that's what's going on. And it was actually a case where it was all templatized and everything. So it was really hard to move it outside the function because for every template, every instantiation of that function, there was a different critical section. So I really had to solve that problem.

And the only thing you can guarantee is that static variables are zero even before the constructor is called. And technically that's not a standard guarantee, but it's pretty much a standard guarantee, and it always works that way anyhow. So you end up writing a constructor that sets a flag saying, hey, I'm constructing this. And then checks the flag to make sure no one else is constructing at the same time. And then you're like, how do I check a flag and then set the flag without anyone changing the flag between my if and my set?

And then you're like, oh, I need a special compare exchange instruction to do that. and then set the flag without anyone changing the flag between my if and my set. And then you're like, oh, I need a special compare exchange instruction to do that. And then suddenly you're in this rabbit hole of doing lock-free programming. So I will tell people to avoid that. Don't go down that rabbit hole. You'll end up like me. That's the long story. Well, so you've been making a series of these videos,

I started to say videos, but talks at C++ Now on lock-free programming and an interesting lock-free queue that kind of have titles like Part 2 of N. Yeah. Yep. It's kind of funny because I've had this lock-free queue in my head for eight or ten years now and it started out as like um it there was this question of can you make a lock free queue that grows and

shrinks and has all these other properties it's kind of like the like the the mother of all lock free queues that can do a multi multi-, multi-consumer, you know, everything. And I don't want it to be node-based for whatever reason. And I was talking with some other guys and they're like, I don't think that's possible. And then I was just like, had this picture in my head. I'm like, I think this is possible. So I don't work on this at any other time except for when I give these talks. And I don't know when it'll get done.

I just make progress. And the first time I gave a talk, I'm like, oh yeah, I'm going to explain this whole cue. And I got to push. That's all I could explain in one hour and a half because it's complicated. And then I realized this is going to be a lot of talks to get to the cue that I really want to get to. So yeah, that's where it is.

And then, you know, the next question is, where do these talks go? Because I haven't done it in a couple of years. I plan on doing it. I'm hoping to do it for CppCon if they, well, one, if I submit, which I have to do soon. You have four days. Yeah, I've got four days.

And hopefully they'll accept it. But I do have this thing that the real purpose of all my talks, all my lock-free talks are to discourage people from doing lock-free programming. It's like, I'm going to explain how it works because I don't want, if you're going to do it, I hope you do it correctly, but more likely you should just not do it. And that's what the real crux of my talks are.

So I've had this excuse for the last couple of years is just like, well, you know, the first rule of lock-free programming is don't talk about lock-free programming. So I haven't been talking about it, but I think I will again. I've gotten out of the habit. It really used to be my go-to.

If I've got nothing else to work on right now, I'll think about that. Like when I'm doing the dishes, anything, right? And I've kind of got it out of that habit. And now I only think about it once a year when I, and that's the worst part. I'm doing it lock free programming is hard enough but when you do it like the day before you're going to present it what's the chances I'm putting bugs in these slides and I my goal my goal is to someday go back to one of my older slides and say hey you guys all believe that this slide was correct

and it's wrong and here's where it's wrong and then that's to show people um you know show people that they shouldn't be doing it because you're just like accepting some so-called expert and he doesn't know what he's talking about so if you didn't if you didn't notice that this was wrong then you shouldn't be doing it so maybe i will purposely put in mistakes in my that's my maybe I will purposely put in mistakes. That's my excuse. I've purposely put these mistakes into my slides and see if anyone notices it. It's actually weird because just the last couple weeks,

we're reorganizing our team a little bit, as we tend to do. And one of the guys I'm pseudo-man'm pseudo managing whatever i try not to be a manager here i try to just write code um because i've done management before and i know i know to avoid it but uh one of the guys i'm pseudo managing uh i just ask him you know what kind of stuff where do you want to grow what do you want to learn and he mentioned lock free programming is one of the things i'm like he doesn't even know that i i give talks on it like he just it's just i was like hey by the way i know something about lock free programming so now i've got this thing where it's like i don't want them to write lock free code in our code base because i i actually you know i i only

do lock free in slides i don't do it at work very often every now and then you're like oh this would really it's the same thing you have to measure it 10 times before you go to lock free programming but now i've got this guy who wants to do lock free programming i'm like cool i can get him to do one i can get him to uh actually code up the lock free queue that i have in my head that i have not i've only i've only put it on I've only, people look at my code on my slides thinking, oh, this must work. It's like, I haven't compiled that. It's on slide, like PowerPoint doesn't have a compiler, right? It's, it's like when you see the, the, the talk or the, the papers, the academic papers, and it's all in pseudocode. And then you try to implement it and you're like, wait a second, you, you know, you left out details. Um, I try not to leave out the details

and I, my slides are in C++, not pseudocode. But, uh, now I've got a guy who's, who's eager to actually code. And so I could get him to actually code up the lock free queue and I could get him to write like performance metrics and tests and all this other cool stuff which i'm too lazy to do so i could actually have you know slides with with graphs and stuff which who doesn't want graphs in their slides um but at the same time uh i have this belief that no one should be doing lock free programming so do it you know I have this moral dilemma right now. It's like, for my own sake, I want him to do lock free programming, but for the sake of the, and I, he's a smart guy. So I, you know, I don't think he'll, he'll be that much of a danger to the C++ community,

but in general, lock free programming is a danger to the C++ community. So that's, that's a long story well i guess you kind of indirectly uh answered the question that i have which was what advice would you give to someone who wants to learn lock free programming yeah the answer is don't just just just run away as fast and i mean and and sometimes i i think now that there is a lot of talks going on about lock-free programming, which in the back of my mind, I'm like, hey, that was my territory. What are you talking about? I mean, Herb Sutter, he was there from the beginning as well. So you can't complain to him.

So there's a lot of information out there. And I think maybe it's been saturated. Maybe we don't need to talk about it anymore but then i go on to stack overflow and the answers are usually good but the questions that people are still asking about lock free programming i'm like some guys just like oh i'm writing this lot thing and i'm doing this lock free stuff and they're like this works right and you're like it doesn't even close to work like it's like what were you thinking and and it's really even close to work. Like, it's like, what were you thinking? And it's really like how many people are out there doing,

and one of the worst parts about lock-free programming is you really can't tell that it's wrong because it will work 99% of the time, right? If you, I mean, even normal code, if you just don't put locks around stuff, yeah, it mostly works. Like, you know, unless you actually hit that window where things are happening wrong and you start doing lock-free stuff.

One of the best examples is the classic double-check locking pattern, which is technically broken. But it's not broken on Intel because Intel's memory model is not as loose as some other processors. So you can get double-check locking wrong and spend 20 years of your life not realizing you wrote the code wrong um and there's a lot of lock free stuff like that

where either because on this platform it's okay or you will only see this bug if um if it these two lines of code happen in two threads at basically exactly the same time. Like the window of opportunity was one line of code, right? Getting in at the wrong point. And I've had that where I was working with another guy who was writing a lock-free or like mostly lock-free allocator, which is one of the most complicated things you're going to ever do. And we had a bug in it. And the head pointer to the free list or something like that was just getting trashed,

right? Being set to null at the wrong time or being set to the wrong pointer or whatever. And you look through the whole code, there's only two lines of code that ever set the head pointer, right? And they're both either in the same function or like next to the one function after the other one. We could see both lines of code on one monitor. And we stared at that monitor for like four hours, just sitting there between two guys going, oh, oh, wait, wait, wait.

I think this is happening. You know, the code's coming in like this. And then this happens. The other thread does that. And then this is why it failed failed and then the other guy would be like no no no that can't happen because we check this here and we set this there and therefore you know that state will never oh yeah yeah right that can't happen we took care of that state and then you just sit in silence for another hour thinking how is this happening and then you're like oh wait wait wait this is it it's like nope we did that i

don't know how many wrong turns we had but we i swear it was four hours mostly silence staring at didn't scroll up didn't scroll down just stare at these lines of code one of these two lines of code is wrong and uh we finally you know had the aha moment of you know know, and it came down to, and this is before Atomics. And so it's a really bad example because the answer was to make a read, a volatile read. And I will tell people volatile never fixes anything in threading. It has nothing to do with threading. But yet in this very specific case, in this old, you know, before atomics, changing a read to a volatile read, fix the bug. And we had to put a 20 line comment, why this, you know, what's going on and why this is necessary. And then I swear, like six months later, I was like, wait a second, that's not

what's going on. It's like our comments totally wrong. The fix was right. It's still the right fix, but what was going on? I was still not sure that we understood the real picture and it just happened to be the right fix, but we had to go change the comment to be like, no, no,

this is really what's going on. And, and you know, I still have nightmares about that code and that code would, we had to run the product for like 30 hours straight before the bug would show up. So the better case is look up the Ptolemy project at, I think, Berkeley, which they wrote a whole OS kernel, all this kind of stuff. And they had all the best practices like code reviews and unit testing. And part of the whole project was let's code with best practices everywhere.

And in particular, in the kernel, they had experts come in to review the code and everything. Like, let's do this the best way possible. And that kernel and OS ran for three years straight. And one day after three years deadlocked there was a bug for three years that didn't hit the window and then finally one day it deadlocked and it's like yep that code's been wrong for three years you just didn't notice wow so you can write all that's the other problem with lock free coding you should write tests but you can write all the tests in the world it doesn't prove anything you have to actually get into provability theory and stuff like that,

which is the other reason why I haven't done my lock-free talk in a while because provability theory is hard, and I should talk about it, and I'm avoiding it. Have you had any luck with thread sanitizer or Valgrind's thread testing or anything like that actually being useful in debugging these things? I haven't because I'm lazy and i haven't done it and okay like i said i i haven't written out my stuff as actual code right so i can't run it but um from everything i hear and i have looked at it and looked into it um and there used to be a thing called relacy i think it was called or

whatever however that's pronounced which also did similar and they all sound like yeah they're doing the right thing um those ones they're good um uh they're really good because they they if if they're if you run the code and there is a window of possibility of like if this happens at the same time as that you're going to see the bug they basically artificially extend that window by the way they instrument the code such that you know if this you know you basically make they can they can see that you have set x and they can track whether there is a happens before relationship with the other threat. Like they can kind of see some stuff, but they still can only instrument and see the code that runs. So you have to have tests.

And as long as your tests run all the possible code, then, you know, they will find logic errors. But it's still not quite the same as provability, right? Provability is just like you don't have to run the algorithm. You look at the algorithm and see it happen. So I do think, I definitely think threat sanitizer and everything. I also think I'm probably not explaining it very well because I haven't played with it enough. But it's definitely better than what we've had in the past. But there is a whole lot of research going on on provability stuff,

which is hard, and it's hard to prove anything besides small examples and stuff like that. But there was actually some work being done on provability of the C++ memory model, and they keep finding small bugs in our memory model that we then fix. You know, nothing that has caused real problems, but, you know. So there is work in that area, and that, to me, is really interesting work, and I have no time to dedicate to it, but that is, someone should be talking about that stuff more. Let me say that right

do you want to tell us real quick uh what your role is with the c++ parents committee like what what group you're on um my role is to stir up controversy i think and uh yeah i shouldn't say i i start i've been on the committee for about five years and you know as the as an average programmer we're all just average programmers you think of the committee as this like those are the good you know those are the guys those are the amazing programmers and they are there's a lot of a lot of great guys out there but so the first time i showed up at a standards committee i'm like i'm not going to say a word like i'm not going to open my mouth because i'm an idiot right and that lasted like one or two meetings and then something happened where i'm like wait a second

that's not right i'm just like that that's just wrong and why doesn't anyone else see it and so then i started complaining about things and like i'm going to speak up in the committee and uh now i think i've kind of like burnt my karma. I've spoken up enough. I should keep my mouth shut. I complained about standard bytes and just, I complained about naming a lot. And to a certain point, you're like, you know what?

Naming is very important. I think it's very important. But at some point you got to go, it's a name. Programmers will deal with it. But I complained a lot about standard optional and it's kind of weird because when i first showed up and i started complaining about like 99 of standard optional i was agreeing with i was just disagreeing with how the less than operator was done which is just like such a small thing um and everyone was like what are you talking about blah blah blah and then with a couple years later everyone agreed with me and everyone was like what are you talking about blah blah blah and then with a

couple years later everyone agreed with me and i'm like what just happened did did did did like you just got to know me now so you you have some more confidence or or actually you know over time it gets explained and people start looking into it better it's kind of sad and kind of amazing how well the committee works with um we're supposed to read all the papers before we show up for a week of committee but you can't read all the papers there's hundreds of papers so a lot of papers are like people looked at really quickly but a really pile of smart people looked at really quickly and somebody in the group will find something. And it makes the standard better. But at the same time, you're like, man, shouldn't we have all spent time before just showing up in a room and actually.

And there's always, that's the thing. We're not, it's not like everyone will look at every paper. But someone has spent time looking at each paper. And it all works out at the end but i'm amazed at how well it works out considering a lot of stuff is you know from the hip i think but it's smart people from the hip so um uh but to really answer your question um i spend a lot of time in lewg doing library evolution stuff which if anyone's going to show up on the committee, it is kind of like the introductory drug of committee. Because, you know, you've probably used the library in the past. Therefore, you could, you know, talk about whether you thought something was a good API or not. And you've, you know, there's a good chance you've written a library of some kind, like

every class is in some sense a library. So it's not hard to have an actual good valid opinion about a library API. Evolution, where you talk about language and language API, that's a little trickier, right? You really have to understand the language better. And using the language doesn't always mean, because a lot of people will be just like, hey, wouldn't this be great if I had this keyword and that would solve my problem right now? It's like, yeah, but how does that really fit into the big picture, right? Keywords are very expensive, and so you have to spend them wisely. And they have to have a lot of power when you decide to make a new keyword.

But I do spend, I try to spend a chunk of of time and sometimes I'll spend more time in in EWG on the language evolution the scary one is core so if you ever show up for a committee meeting you go into core where they actually do the language, lawyery you know, standard E stuff

it's, no one talks in core. Some guy would be like, I think we need a comma here. And then it's just quiet. And then some heads nod. Someone grunts. And that means everyone agreed. And then they go on to the next topic.

And you're like, what just happened? Are you guys telepathic? And so I've been to core like once or twice. And the first time I went to core, and I actually spoke some words and people agreed with me I was like yes I'm never going back I've I've successfully gone to core and they didn't think I was insane and then later on I was talking to uh um Jens the other Jens uh who was taking minutes when I was there. He was like, you were in core. I was like, Oh God, do you mean you didn't record the minutes of me saying something that you guys agreed with? See, I'm sure he wrote down something and a conclusion, but he didn't

realize it was me. Cause you know, they just, they're in their zone of looking at wording. And I was like, so there's no proof that i actually ever went to core and said something sensible i don't know if that means i have to go back someday i i might i don't know i might not go back to core it's it's a great everyone should should experience it there's it's it's different because they don't vote for another thing every other group in the committee will vote on it's just straw polls it's not a real vote, but you know, get the opinion who agrees, who disagrees when you're in core.

They, they have to conclude with, they all, they all agree or not. Like there's no voting. It's just, yes, we've all telepathically are on the same page.

We're all in the same mindset. And that's how core works. They never raised their hands. They never vote on anything. Interesting. It is. Okay, Tony. Well, the same mindset and that's how core works they never raise their hands they never vote on anything interesting it is okay tony well it's been great having you on the show today uh where can people go and find your stuff online um they can go to uh they can find see my talks on the boost con channel and the cpp con channel on youtube they can go to my github t van eerd um there's a the there's a among other things i put i put my standards papers there the ones i'm working on the ones i've already done so you can go and like tell me that my next proposal is dumb feel free to to add stuff to

that and i have uh pages there on c17, which seemingly got really popular. And sadly, I haven't done a lot of open source work in the past. I mean, the standards committee is technically open source. But I haven't had a chance of writing a lot of open source code. So I put my pages on explaining every feature of C++17 up on GitHub. And it's like, people just fix your bugs for you. It is, you know, it's the best thing ever. All I do now is say yes to pull requests to those pages.

I'm like, oh, yeah, you're right. Either that was wrong, I actually got it technically wrong, or, like, that would explain it better. I'm like, yeah, here, I'll just accept that. It's like, I wish all my code could be there. Okay, well, it's been great having you on the show today, Tony. Oh, and also Twitter. You must follow me on Twitter.

I now, all my talks, my whole talk was Twitter posts. That's, I now just do my outlines on Twitter, I guess. So it's my new medium. My next topic is C++ cones. So, you know, coming soon to Twitter near you. Okay, thanks again, Tony. Yeah, thanks for joining us. Yeah, this was great.

Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. And of course, you can find all that info and the show notes on the podcast website at CppCast.com.

Theme music for this episode is provided by PodcastThemes.com.