CppCast - Defer is better than Destructors

Episode Date: April 30, 2021

Rob and Jason are joined by JeanHeyd Meneide. They first discuss alternative operators in C++, upcoming virtual conferences and papers in the April ISO mailing. Then they talk to JeanHeyd about his work on the C and C++ committees, including embed, defer and more. News Just discovered C++ has keywords 'and'/'or'/'not' etc. Pure Virtual C++ April Mailing Links Defer Mechanism for C: The Movie p1967 Preprocessor embed - Binary Resource Inclusion p0052 Generic Scope Guard and RAII Wrapper for the Standard Library No Us Without You - elifdef and elifndef CoSy Tech Con Sponsors Incredibuild

Episode 297 of CppCast with guest Jean-Huidh Manid recorded April 28th, 2021. Today's episode is sponsored by Incredibuild. If you're like me and don't like waiting for long C++ builds, tests, and analysis results, then you should check out my friends at Incredibuild. Because expert developers don't wait. In this episode, we discuss alternative operator keywords and more ISO papers. Then we talk to Jean-Huidh Manid. Jean-Huidh talks to us about his work on the C and C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right, Rob. How are you doing? Doing all right. I realize we haven't talked about conferences in a while, but C++ Now is coming up soon, right, Jason? It's like next week. Yes, it's next week.

I should know that. Because it turns out I'm speaking at it now. It turns out you're going to be speaking at it. What are you going to be talking about? The title of the talk is The Worst Best Practices, and it's kind of um well okay i'll go ahead and give a little sneak peek here so that the premise of the talk was going to be that i would talk about you know just the process of writing a book in the 2020s and what that looks

like self-publishing and whatever and then what kind of uh controversies or whatever that I might have brought up by publishing a book on best practices. Interestingly, it's kind of turned into a little bit of like a 15-year retrospective because I realized as I was starting to write the notes for the talk that my first notes writing down things that ended up in this book were 15 years ago. Oh, wow. It just makes me feel old. So in a way, the book is 15 years in the making. And are listeners still able to go get virtual tickets for C++ Now? Oh, yeah.

They definitely still want people to sign up. Okay. So that's cppnow.org, I believe. Yeah. Okay. Well, at the top of every episode, I'll let you read a piece of feedback. This week, we got an email from Rory saying,

love the podcast, one of my favorites. I saw this post recently, and I'll link to that in the show notes, regarding modernizing C++ support in the OpenJDK VM, which has some interesting notes on the specific features they feel would be beneficial to permit in the code base from recent C++ support in the OpenJDK VM, which has some interesting notes on the specific features they feel would be beneficial to permit in the code base from recent C++ standard iterations. I thought it may be interesting at some point

to hear from one of the devs on the project, which is one of the most widely used and deployed runtimes written in C++. That is interesting. I thought this could be a good topic for a show. We did do one show about Java a while ago, but Java from the perspective of this Java VM written in C++ and specifically the JDK, the Java Native Development Kit. I think that's what they're talking about, right? JDK, Java Development Kit, yes.

Yeah, yeah. And their support for C I think, could be an interesting topic. Yeah, well, okay, now I just made myself sound old again. But OpenJDK has its own whole history because there wasn't an officially licensed Sun version of the Java virtual machine for Linux back in the mid-90s when it first came out. So there became an effort at the same time. I'm pretty sure OpenJDK actually goes back that far, back to 97. That sounds right. I did not know that.

Okay. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email at feedback at cppcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Jahneed Manid. Jahneed is a student at Columbia University in New York.

Most of their programming is for fun and as a hobby, even if their largest open source contribution, Sol2, is used across many industries. They are currently working towards earning their own nickname, climbing the academic ladder, while spending as much time as possible contributing to C++ standardization and development. Their newest and biggest project

is Unicode for C++. They also very much love dogs and hope to have his own in a year or so. They also like TWRP's Feel Pretty Good from the album Together Through Time. Shanheed, welcome back. Hey again. I think this is the third time I'm here. I think so.

If you're including the time you guest hosted. Oh yeah. Wow, I've been on here a lot. Who's the record holder at the moment? I believe it's still Sy, I think. Has he been there like six times? Something like that. I could look it up real quick.

But I believe Sy Brand has been on the most. Yeah, six. Six episodes. They've got a good record. Yeah. All right. Well, Jean-Huid, we've got a couple news articles to discuss. Feel free to comment on any of these, and we'll start talking more about what you've been up to lately okay

all right awesome okay so this first one is a post that was on the cpp subreddit um just discovered c++ has keywords for end or not etc and that is like the word and spelled out, which you can use instead of the common and operator. And the code sample for this like really kind of hurts your eyes. I definitely didn't know this was something you could do. What do you think about this? So, um, so I know about it. And I am aware of the keywords. I've kind of decided not to use them at the moment. But I think that's mostly because MSVC beat them out of me because all their compilers just work normally with them. But with MSVC, if you don't have the permissive flag or whatever,

you have to include a header to get them. Right. So it's absolutely a pain in the half to use with MSVC. Again, most new products default, obviously, after MIS-Syvan and all other stuff. But other products don't. And so people kind of complained when I did use them, even just in Jest a couple of times.

So unfortunately, I wasn't able to really get used to them so much. I kind of, again, I trained myself out of them, which is a little bit sad. Because in some cases, they do make things nice, especially when you're working with templates and you're like composing the gigantic conditionals that go into like a template. I mean, you just have like a little, you know,

exclamation point in some places to negate stuff. And it's like, it's completely lost in the line noise. So just having not space is like a really good visual indicator, like, okay, I'm negating this thing in my, you know, four or five lines of template shenanigans. Yeah, five lines of Sphenae, you've gone too far. Yeah, I mean, that's what we'd like to say.

But then you look in the standard and like, you know, the constraint structure is like, is not a array and is not, you know, it does not decay to an element of the base class type. I was like, oh my god. So yeah, some of us take that advice hard, but the rest of us not so much. I actually know one team that uses this exclusively. They don't use the traditional operators. Oh, wow. What is their reasoning for that? I would say they would say readability okay actually um but then every compiler implements it in a way that's not in my opinion quite right and so if you look at the first uh comment on the reddit discussion my class and other and you just put like an r value

reference by using the and keyword there and like every compiler allows that and it's not quite right somehow and so that's my feeling on it is like nah okay never mind yeah yeah i think what was the first the first comment after that one is thanks now i hate it yeah yeah yeah that'll that'll definitely do it um i'm assuming that the team you're referring to, Jason, probably would not write that code, but they're using it for actual logical and. Yes. But I mean, would it really be C++

if there wasn't a fun way to shoot yourself in the foot with it or write something crazy with it, right? Yeah, yeah. Next thing we have on the topic of virtual C++ conferences, pure virtual C++. The signup is now live and that's going on next week. So if you haven't already signed up,

you should check it out. I guess that does overlap with C++ now. I guess so. I don't know. This is just a single day. This is May 3rd. Yeah, it does overlap. Yeah, it's plus. Okay. Okay. And C++ now is, that's what, three or four days? Yeah, it does overlap. Okay. And C++ Now is three or four days? Yeah, it's the

second through the fifth. It's a five-day conference. It's usually five days with I don't know. I don't know what the schedule looks like. It's usually just like a week for the business week. That week is when it lasts.

But yeah. Sorry. Yeah, but I'm kind of excited about a pre-emergency i think i'm definitely excited about uh uh daniela engert's talk the uh the secrets the three secret spices of cs plus modules um because i i so so i have uh i don't know how to use modules properly i mean, so I've seen Daniela give some of the talk before, and I've seen like build improvements, other things that can come from modules, but I think that this talk is probably a more improved version of that, because the last time she gave this talk, she was

basically fighting with, what was it, all three compilers that had incomplete implementations in each modules, and they each were incomplete in completely different ways, so you had to tailor your code for each different one. But basically, I think this will be a much more improved talk. And so I think I'm interested in watching that one

so I can learn a little bit more about it. Also because I need to work the hatred of modules out of my system steadily and slowly. I ran into some unfortunate things about modules and the way they interact with the preprocessor when it comes to std embed. And so my life was just, the whole proposal was thrown into limbo

because I had to figure out how to make this phase four hash depends thing work with std embed, and it's kind of a mess, and so I got to figure it out, which is a little bit unfortunate, but that's where's a fascinating sorry go ahead jason fascinating overlap for me from a c++ weekly perspective because like once every 10 days i have someone ask me when am i going to do an episode about modules and i'm like i don't know after the compiler support it and i

know what i'm talking about you know right but then also i just had someone recently say that i really need to do an episode on stood in bed so oh oh well um is stood in bed is going to take a little bit longer um so you know you want to do an episode that that quickly uh but um you you will be able to you should hopefully be able to do an episode on Clash Embed, which is the preprocessor version, which isn't quite as powerful as Stood Embed, right? So Stood Embed, you can use a const of out time, you can use it like recursively, you know, because it's just a normal const of out function,

you can use it recursively. At compile time, you can basically implement like a C compiler in, you know, C++ const of out using this kind of thing, right? Clash Embed is a preprocessor thing. You can't react to the fact that the preprocessor included it and then hash embed something else, so you can't get that recursive ability anymore. We also remove the ability to specify types with hash embed,

so all you get out are just blobs of basically a bunch of numbers. The way it works is that it of, are basically a bunch of numbers. The way it works is that it basically dumps out a bunch of numbers that go from zero to whatever the UCAR max is supposed to be. Which is maybe 0, 2, 5, 5 on all normal, regular, sane systems. So, you know,

and that's just how, and that's just kind of what it does. So it's very simple in that way. But again, you don't get the due types it's not const of value you can't react to things so there's a lot of room i think left on the table for std embed um but i think hash embed is like a very good a very good thing for like quick crixes um and just people who just like i listen i need data array and i need it right here and i just need to splat all these numbers i need to compile it or not, you know, spend five gigabytes of RAM trunking through this array,

this gigantic array that I wrote, right? So that's good. But it is a string literal or an array literal. No, that's not a good word. Yeah, it is. So no, the way it's, it literally just actually dumps out

numbers now, so it doesn't include the curly braces, so it's literally just, it's supposed to behave. So it doesn't include the curly braces. So it's supposed to behave like a comma-delimited list of numbers, right? So a naive implementation could do the wrong thing where they just kind of vomit out the numbers in the spot and say, I'm done. But most of the implementations have had some amount of optimization put into them. For example, my experimental implementation uses a built-in that sits in an array and expands to the right thing, and it's really fast, and obviously it's cutting edge, and there's a bunch of numbers on the

GitHub page, github.com slash the phd slash embed or whatever. But it literally just acts as if it dumps out a bunch of numbers, and that's how it works. So can I use this on any compiler that's currently shipping? No, not yet. But good news is that I synchronized with both C and C++. So I think it'll take a little bit longer to get in C++, but C is interested, and it's actually getting pretty close to acceptance. It might actually get accepted either next meeting or the meeting after. So it'll be in C23. And the good thing about that, it means that Microsoft can't escape anymore,

and they can't keep pretending that they're 64,000 or 65,000 bytes or whatever limit for string literals is good enough. And we'll actually have a way to put large data files in MSVC without waiting a million years for it to finish. And that's actually like 99% of why I'm standardizing this, because MSVC didn't fix their string literals processing. So that's it. That's why I'm standardized. It's because MSVC didn't fix their processing. So that's it. That's why we're here. And so now in my vengeance, it's not only going to be in C++, but it's also BNC. So that, you know, anytime they

implement the next standard, it's going to be there and they can't escape. That's hilarious. Okay. And then the last thing we have is just the collection of papers for WG21 for April. A couple new ones here. I didn't read through some of these in too much detail, but I did see a couple interesting titles, like Constexpr Class.

I thought that one might interest you, Jason. I missed that one. I missed that one. I usually just search these things for Constexpr. It's 2350 by Andreas Fertig. Fertig. Fertig, yeah. 2350.

Yeah. Are you familiar with that one, John Heade? A little bit. So I saw some of the discussion that kind of led to its creation. But basically, I believe the idea here is that you can essentially mark a class as constexpr, and then rather than going through and marking every single member function constexpr, it just assumes that it's constexpr. Everything inside is constexpr.

So you basically say this class is constexpr, everything inside is supposed to be constexpr, right? And it helps catch class of errors where you forget to constexpr something. And there's been implementations that have shipped stuff, and they're like, oops, we forgot to constexpr this thing now. I guess we have to wait until the next update to get a properly constexpr variant or whatever else. So, yeah.

I think it's helpful. I think it's good to just make things easier and not have people suddenly dropping constexpr on the floor. It also kind of signals intent better. So if you forget constexpr on a single method, someone's like, did you mean to forget it there?

Was that intentional? But if you just put it on the class and it's like, okay, everything in here is supposed to be constexpr, that makes sense, right? So I think it's a good thing. I think it'll be great. Yeah, I think the only thing that this proposal doesn't do is it doesn't allow you to backdoor your way out of it.

So if you put constexpr on the class, you can't mark individual methods as, oh, by the way, no, I don't want the constexpr here. You need the no constexpr keyword, so you put no constexpr in front of the... Yeah, in front of the math.

So there's a tiny amount of precedent for this. Some people have already proposed like a constexpr with parentheses and a Boolean, and then you can kind of like do static compile time not to say whether it should be constexpr or not. It was rejected, but I think maybe with this proposal, there might be some need for it. I do think that there might be some cases or classes

where most of the thing is compile time, but you want to specifically say, this thing, though, is not a compile time method. Like, I have a caching method or something, right? And that works off a runtime cache that I'll never be able to access at compile time. This method can't be constexpr, right? So I think those kinds of cases will be a little bit important.

I haven't told the author this, but, you know, maybe I can can can, you know, just talk to the author and they can and see if they how they warm up to that kind of idea. But, yeah, it's I think it's a good paper. It's a good paper. Yeah, I totally forgotten that I had seen this discussion on Twitter. He was soliciting feedback for what the layout should look like for the paper. I mean, where where theexpr keyword should go, specifically. Yeah. Any other interesting papers either of you want to bring up in the April mailing?

Well, there's another one from Andreas that I did see, which was making unique pointer constexpr, which in my opinion is like a huge oversight from C++20 because if you've got constexpr vector and constexpr string, you can make unique pointer constexpr. That should have just been done. But anyhow.

Yeah, so that one's got to get in too. You know, that's like for obvious reason, that'd be a great update. That'd be a great thing to have. So I'm looking forward to that one, definitely. Yeah, but I think, I mean, I put a paper in there, but it's just an old rehash of a paper that I had

for, what is it, Reconstructible Ranges? I think I talked about that a couple of times before and wrote a lot of blog posts about it. But basically, it's a paper just if you take a range apart into its iterators, you should be able to put it back together, or you should be able and do some cool stuff with it. That paper is back in the in the fray

now maybe for c++ 23 oh and that's right uh so out pointer i was wondering about out pointer yeah yeah so so out pointers in this mailing because it actually got through lwg review um so it's going to be in c++ 23 so you'll be able to take smart pointers and have them interact with uh c style functions that take like double pointer output pointer parameters and stuff like that, and it'll just make them magically work. Oh. So that's going to be approved for C++23. I was hoping that the paper would come along with Isabella Muerte's retained pointer, the intrusive pointer style kind of pointer. But unfortunately, that's got to do

that's got to spend some more time in an lwg lewg and stuff so uh library evolution work group the the design group before it goes to the wording group um but yeah i'm super glad that out pointer made it and it was a very long time coming um and i'm actually kind of really glad that's in this is one of those small things that i've like i don't think is a big deal a lot of people don't think is a big deal. A lot of people don't think it's a big deal, but it turns out that a lot of people keep re-implementing it over and over again. And it turns out that there's some performance optimizations that only the standard library can do that I've actually been doing in my implementation,

but through UB type hunting. So I reach into your unique pointer, and I catch it to a struct that has the pointer and the leader, and I rip out the pointer from it and then throw it in the out pointer, which is pretty illegal, but it works. So I'm... It's not illegal

to type on the same initial sequence. That's the same initial sequence rule should allow that, right? So sort of, right? I don't actually know if the struct I'm using matches what's compiled. Like,

so basically I have like a bunch of stuff for like, is this lib C plus plus do this? There's lipstick C plus plus do this. If it's Microsoft do this. So it's pretty illegal. They can change it at any time. Right. It's not guaranteed to work.

I don't think they will because you know, ABI stability and all other stuff, but you know, it's, I'm, it works on, it works on very shaky and tenuous ground. And if the compiler decided to be mean about it, they could ruin my day. So I'm just glad it's in the standard now and I don't have to keep chipping radical undefined behavior to people,

which is great. Okay, so should we break the ABI or not? Yes. I want to go on such a bad rant about ABI, but we will not get to any other part of the show if we start talking about APIs. I will completely refrain from doing that. But to sideways answer your question,

yes, you should break ABI, which means, yes, that my outpoint for implementation that I'll have out in public would break sometimes right i'm perfectly okay with accepting that breakage if that means we don't you know ruin things for a lot of other people and ruin things and i think more insidious ways than i think people realize but again i i'm gonna resisting the urge to rant so eventually yeah a little rant uh well then uh to distract you i'll ask you your opinion on one other thing in this mailing, and that's the if const eval to get rid of the if is constant evaluated. Yes.

So I was actually pretty against if std is constant evaluated, like the spelling of if and then no constant instead is constant evaluated. I think that was a huge mistake. Almost universally, everybody who reflexively uses it pipes out if constexpr std is constant evaluated. And that's just objectively the wrong thing to do, but it feels so right. It feels like exactly what you should be doing. But it's objectively the worst thing you can do with that feature

because what it says is if evaluated at constexpr time, this condition, right? So the condition has to be evaluated at compile time. So st says is if evaluated at constexpr time this condition right so the condition has to be evaluated at compile time so stood is constant evaluated will always return through so if you say put slow code in the constant valve path that's that's constexpr friendly right like you just tank the the the the runtime of your algorithm forever but and because it's constexpr that is a subset of valid c right? So you will never notice that your brand, that you're always taking the wrong branch. If you write that code,

unless you just notice a massive performance degradation, degradation or something. Right. So it's very painful to, to have a thing. So if constant value removes that, because it's just, if constant value,

and it's very clear that you want to switch on the fact that it's compiled time. I've softened my objections to std is constant evaluated a little bit because some people have done interesting things like this. So they have an if statement, they say std is constant evaluated, and then they add a bunch of other conditions for other things that should be true along with the constant evaluation. And so people develop complex expressions for that.

And I think that some of that is a little bit necessary, especially because of the way if constexpr, if consteval, and some of that stuff works. Like if you use an if block, it introduces a new scope. And sometimes you want to share some code. And if you have to put it in like an if block, an if constexpr block or whatever, and you introduce a new variable,

like you can't like really write over it or set stuff. And so I think that there's still some room for if std is constant evaluated and some other stuff, but at least we have if constant eval now, so at least we can drive most people who will just be doing the basic is this compile time or not switch to use if constant eval and do the right thing.

And the people who have more complex conditions can drop down to a lower level of abstraction, the std is constant evaluated evaluated and make complex stuff happen. That's an interesting point because I was kind of wondering if this would effectively deprecate is constant evaluated. Yeah, I think for the most part it kind of does. But there again, there's some of those advanced use cases where you need an expression that can be slotted into an if statement or something else. There might be cases where, need an expression that can be slotted into an if statement or something else. There might

be cases where, for example, you want to base the note. Well, no, that doesn't work. There are some cases where you want to be able to mix that expression in with other things that aren't evaluated at compile time. And also one of what a little bit of code duplication. Instead of having an if-const-eval,

which makes a new scope, and then you have to fill everything in there, you can kind of mix things a little bit, which I think is okay. Right. Yeah. Okay. Well, Jean-Huid, I know you're always a very busy person. What have you been up to lately that you want to talk about? Where should we start?

Maybe what you've been up to with the C standard committee? We talked a little bit about embed already. Yes. So the C standards committee is making amazing progress. Um, at least amazing from my perspective, because I went in there, I was like,

nothing's going to change. I'm going to spend like five years here and nothing's going to happen. We'll get, we'll like, we'll like fix some, you be in some libraries somewhere. And then like, that'll be what we're doing.

But no, the C committee is pleasantly surprised me in that they are very hungry for fixes to a lot of their problems. Right. So they were receptive to embed. Um, they were receptive to a lot of different other papers. They're even talking about a defer feature for C. And I'm not sure if it'll make it for C23, but I'm actually really excited about that. What was the feature? Sorry. It's a defer feature. So it's not exactly like goes defer. It's basically kind of like destruct. It's like destructors for C, right?

So you make a defer block and you basically say all the stuff in this defer block gets executed at the end of the scope, right? In its simplest form. And so it essentially does, it's basically like a destructor, right? When the lifetime of the defer block ends, you run all the statements in the defer, right?

So you do an F open and then you put your F close in the defer and right? So you do an F open, and then you put your F clause in the defer, and then whether you go to or whether you return or whether you just jump out of the scope or whatever else, that defer code is run. Yeah, like a destructor for a function, effectively, is what it kind of sounds like. Basically, but it's scope-based.

So you can have a defer inside of an if clause, and when you exit that if clause, then that's when it engages when you enter the if clause, and it fires when you exit that if clause, then that's when it engages when you enter the if clause, and it fires when you leave the if clause. So it's very much like the destructor. Can we get a proof of clause too? I hope so, but right now we're focusing on doing it just for C, because

I think C needs it most. And the person who's pushed the paper, Robert Secord, has spent a lot of time working with a lot of people trying to make it happen. He has presentations on it. He's working really hard on it. I actually do think it's... a lot of people kind of trying to make it happen. He gave presentations on it. He's working really hard on it. I actually do think it's a lot of people think that it's just destructors for C, but it's actually literally fundamental than destructors. So destructors are always paired with constructor, and they're a general purpose-undue mechanism, as Scott Myers said.

But destructors also carry with them some baggage, especially when it comes to the standard library. The reason we don't have, or one of the reasons we don't have ScopeGuard, that thing that Peter Sommerle was working on for a million years, that was the realization of, what is it, Andre Alexandrescu. Yeah.

It was his idea for, like, if there's a transaction and something happens, roll back the action, right? And so that was basically, that was modeled off of using his idea for like if there's a transaction and something happens roll back the action right um and so that was basically that was modeled off using constructors and destructs right so constructors set up the action and then based on conditions fire any number of these you know transaction failed or the block exited normally so it's okay or the block exit was an exception so do this instead right that kind of thing um and so p Sommelak created this paper, I think P0052, that was ScopeGuard.

That was what the paper was about. But fundamentally, that paper doesn't work with the standard library because every single type in the standard library must have a no-accept destructor. If anything is destroyed in the standard library, it doesn't throw an exception. We take this so far that even for things like file buff or threads or whatever else,

any exception that happens in the structure, we just swallow it and throw it away. Every single standard library does this, right? And even in some place in the wording, we say, if an error happens while the structure is going on, just swallow it and just throw it in the trash. Students made me aware of this because apparently close can

fail, which I had never considered that file close, not F close, but like, uh, uh, O F stream close could fail. Like it might not have enough space to write to it. And if you're just relying on the destructor as I do, then you completely miss that an error may have happened when the, when the file is closed. Yes, exactly. And so one of the reasons why ScopeGuard couldn't make it into the standard is because we would have to fundamentally reevaluate what is the stable tag? Res.on.exception or whatever. But basically that says no standard library type will have a throwing destructor.

Every single destructor will be non-no-except. I'm sorry, will be no-except. And we will never have a non-no-ex throwing destructor. Every single destructor will be non-no-except. I'm sorry, will be no-except. And we will never have a non-no-except destructor. And the single thing about ScopeGuard is that we're running arbitrary functions and some of them can throw and it's desirable to react to that, right? Especially if you have nested ScopeGuard

where you're testing if something upstream failed, then yes, even if this scope guard failed, the next one should be able to catch it and do something about it, right? But the way the standard library works is that every single type inside the standard library can't throw. So you come up to this very strong barrier between the rules of C++ standard library and this very useful functionality. And the reality of the matter is that you really can't have it in a C++ standard library that goes full in on not having any kind of throwing destructor.

So the only way to have this feature is to actually have the deferred feature that C is working on right now. Because the language doesn't particularly care if you throw or not in destructor, that's just whatever. But if an object throws, if a standard library object throws, that's a big problem, right? So by having defer in

the language, you can get around the fact that the standard library can't handle this kind of thing. And so now you can write a defer clause that does all the things that Andre Alexandrestou had envisioned with ScopeGuard without needing the class spoiler plate and having to create this type that holds it on this Lambda for a million years.

You can just have the first statement do it instead. And so that's actually a huge win that I don't think a lot of C++ people realize is there for people who want to do better transactional programming, better guaranteed if somebody throws an exception or whatever kinds of programming without having to roll their own scope guard or whatever that entails. And so I think that a first statement actually has immense value to C++, not just C. And so that's what I mean by it's not just destructors,

because again, destructors have this connotation that they're always no except, right? And of course, you can't pass arbitrary information to destructors unless you toss it into the constructor of the object, right? And then you have to hold it and stuff like that. But defer can do it much more efficiently, right? Because just again, this is a scope-based statement.

So I think that actually has a lot of room. I'm actually very excited to see where it goes for C. I expect that C will get it first, and then slowly we'll have to start whittling out the C++ committee and be like, no, listen, this defer thing is actually really cool. It's not just destructors. It's actually a more general-purpose undo mechanism than what Scott Myers had said was a general-purpose undo mechanism, constructors and destructors, way back when. So I think it'll take a while to warm these people up to it, know that's what i'm talking about on cfp cassey you know the idea

in people's heads and like uh defer is a good thing for c++ yeah yeah that kind of thing um but you know i have questions yes like when you're in the defer block are is that is it is the the previous scope is it still visible to? Do you have access to those? You must, because otherwise you couldn't call fclose, for example. Yes. So you have access to everything in the previous scope. So it's basically like you can just refer to everything there. And it works.

You can also, if you want to be safer about it, you can capture a lambda and capture the variables by value and then pull things in that way to make things safer. And there's also another thing that's actually exciting about it. You can capture a lambda and capture the variables by value and then pull things in that way to make things safer. And C is also another thing that's actually exciting. C is working on getting lambdas, which is you know, that is a big thing.

But I think it's a very big deal for C because a lot of higher level programming in C is basically done with extensions like either nested functions or I think I learned that Orlan C has a special wide closure type or a double underscore closure keyword that you can annotate with function pointers to make a closure type that contains both the function and like more data and stuff. So it's, I learned a lot being part of the C committee and being the product editor. But yeah, they're, they're getting lambdas. And, you know, so that thing might help with

lifetime and other stuff that comes up with how defer works. But I think that because defer is locally scoped, you can't eject a defer into a higher scope, right? So fundamentally, you're going to be running to defer with all the variables still, all the

variables that you referenced there. So you would have to allocate a variable, delete it, and then run the defer like a smaller scope, but in order to like make that kind of, right. So it's, it's still safe, but obviously you still run the problems of if I capture something by reference or by, by pointer in some other scope, then obviously you can represent and defer and then blow something up.

But it's, it has the same kind of properties of that. You know it always deletes stuff at the innermost scope and you can represent and defer and then blow something up. But it has the same kind of properties of that, you know, it always deletes off the innermost scope and you can't like, you know, accidentally refer to something that might, that by normal by value rules would have blown up by now. Right. Okay. Yeah, that's what I was wondering is if the destructor of an object

were to throw an exception and then I was going exception, and then I pop into my defer block, how do I know which object threw that exception in its destructor, and what happens if I try to access that? But it sounds like that would prevent... Now, again, they haven't really hammered out these details because, again, in C, there's no destructor. Everything, like, object lifetime ends when you leave the scope. Defer is before you leave the scope. So for them, everything's kosher. I think in C++, you'd have to have the discussion of when exactly does defer run. My preference would be before destructors

are called because you want to, you know, you want to be able to help this thing still. Yeah, I think it would have to be. Like, either that or you'd have to figure out a way of, like, you know, you want to be able to access things still. Yeah, I think it would have to be. Yeah. Yeah. Like either that or you'd have to figure out a way of like, you'd have to weave, you'd have to say that the first statement triggers in the order of declaration, right? So the same way that destructors are done in reverse order, right?

You would do the reverse order of destructors and then whatever the first statements happen to interleave with those, right? In that kind of order. So if you declare one variable, do a defer statement, declare another variable, right. You delete the second variable first, then you call it defer. Then you do the first variable, right. Like in that kind of order.

So you can maybe do it, you can maybe do it like that. But again, that's like, that's probably, that's, that's probably the best way of doing it, I think. But, you know, so basically anything that you could refer to and defer would be anything that comes above it right and by that logic like everything above it has a lifetime that is longer than the first

statement right right because again because things are always destroyed in reverse order so anything declared after it would be destroyed would destroy itself for the defer block runs and you can't refer to anything after you know the first statement so it's it has the same kind of rules as the the first statement so it's it has the same kind of rules as the destructor right so it kind of starts to feel like if a knit blocks where

when you show someone if a knit they don't expect that the else block would have visibility to the thing that was in the infinite statement and then if you nest them and nest them and nest them you know like if a knit if a knit whatever whatever then by the time you get down to the fourth statement you actually have visibility to all of the previous init blocks. People don't expect that, but once you understand how it was structured, then it makes sense. And I kind of feel like what you just described

feels the same and would make sense once you, you know, maybe you wouldn't get it immediately, but then you'd be like, okay, I see what's happening here with the interleaving. Yeah. So that's what's been going on in Sealand. I'm also, I'm actually working really hard. They added a new annex to C for binary floating points.

So they added a whole new extension for binary floating point, and they also cleaned up a lot of the math in C. So they are now basically, I believe, almost perfectly conformant. There's some differences, but they're almost basically conformant with IEEE, the new floating point IEEE standard, the 2019 or 2021.

And so basically, they're all, they have all the functions, they have all the binary floating point functions, and I have to integrate that NXX into the C standard, and that's what I'm doing right now, on top of all the other papers that got accepted. So I'm desperately beating the late tech up.

God, I hate late tech so bad. It's not fun. It is absolutely not fun, but it's what we have. And I'm actually pretty grateful that it is late tech because before it was some like froth and a mix of some other stuff, which is like some like half dead file format. J yen's gustad um who's also you know spent a lot of time on c committee a lot a lot more before i showed up um who is the one who's proposing lambdas and a bunch of other like

revolutionary even the null pointer constant they're bringing that into c um so it's it's actually getting really spicy in there um um but uh yen's gustad was the one who was the editor before me and he did a lot of work to translate everything to LaTeX. And as much as I complain about the LaTeX experience, like I, there's some little, like little parts that are left in the old froth for like the, for, for, for the way the old standard was. And I'm like, I'm so glad I never have to touch. I never had to touch any of that because it just looks like all, it looks like it's all

a nightmare. Um, so many thanks to Jens Gosted for that one. But yeah, I'm not having fun with LaTeX. I'm really not. I don't know if it would be useful at all, but I would just share that there's been this WYSIWYG

LaTeX editor that's been around for like 20 years that's not very well known called Lyx. Lyx? If you haven't seen it i i mean i haven't tried to use it in like 15 years so i can't even comment on whether or not it's useful right now but uh just thought i'd throw that out there okay yeah definitely i mean right now i'm using like vs code and just like uh and just a bunch of like shell commands i can't even run it in windows right now i mean i'm actually trying to i'm trying to improve the build system so that I can build on both Windows and Linux,

but right now it's all WSL2 land. It's all VS Code with just running raw commands and hoping the thing builds and getting a million spews of overfull HBox. Yes, overfull HBox. At least thousands of those errors. It's just not a good time. I'm sorry, I have to ask a question about what you said you're integrating. What the heck is binary floating point?

So binary, there's a binary floating point and decimal floating point. So they added extensions for both binary floating point and decimal floating point, which basically is just two different versions of handling floating point numbers. So like literally 1010.10. Yeah, some of that, and then also a decimal version of that so um for and the the format isn't exactly hammered in stone the i think

implementation i'm still trying to understand all of it right and this is what this is why i'm taking so long to edit the things i'm like need to make sure that i'm putting everything in properly and not like oops i accidentally changed the meaning of what they meant by binding floating point um but it's it's it's basically basically there are two different storage formats. Binary floating point is the stuff you're already used to and what you get when your floats and doubles today. It's a binary storage format. Decimal floating point is closer to what you would expect

from your arbitrary digit precision libraries. So some of those storage formats um they don't support arbitrary digit uh floating point obviously but um you know they support you know very strong forms of of decimal floating point and uh uh that's basically what i've been dipping my hands into and i'm learning way too much about floating point errors and other stuff that i need to make sure is um make sure it's on'm, I'm actually terrified of submitting the draft because I know that I'm going to mess something up and like the, and so there's a whole group body of the whole C floating point group. And I'm going to have to like report to them like, so how badly did I do? Um, but you know, I mean, thankfully it's

not too hard, right? Basically most of it is just copy pasting verbatim and making sure that I get the typesetting correct. Um, but you know, again, in, in typesetting an entire annex of the C standard, it's it's, it's something. So it's been taking me a while. Also the, the diff, the diff engine is busted. So I have to fix that too. So there's a lot to do. There's a lot to do.

Are you glad you volunteered for this editing job? Yes. With reservations. Yes, with reservations. Yes, with reservations. But I am happy because I am getting a chance to revamp the paper process for C.

So W21 has its paper system, right? You can finally now submit papers online and you get these P numbers and they're not tied to the ISO system. C is still tied to the ISO system. C is still tied to the ISO system. So you have to submit a paper to the convener or to the, what is it? I forget Daniel Pocosh's full title. But you basically submit it to either the convener or Daniel Pocosh and that's how you get a paper number and it goes through the ISO system. So they literally send like an email or request to ISO. ISO approves that request and then you get back

a chunk of paper numbers and you start handing them out, right? And that process can sometimes take an exorbitantly long amount of time. ISO is even complaining that we're asking for way too many papers. So like we do need a new paper system. So I'm actually working on that. And I actually, for the next C-mailing, I'm hoping to actually write a paper, write one of the last N-numbered papers that is how to submit a paper into the new system. And I think it's pretty cool. And the good news about this is that

instead of kind of having things like WG21 link as like separate services, it'll kind of be built into the infrastructure of WG14. So I think, you know, it's going to be good. I don't have to do this stuff as a product editor, but I think it's still worthwhile to kind of give a place for people to easily submit their papers because I've gotten way too many emails. But if you're like, how do I submit a paper?

And it's like, oh, well, you have to go through this very grueling process. Good luck. Um, and, and I'd like that to not be the case anymore. So, um, I'm working a little bit on that and hopefully, you know, in the next mailing, I'll be submitting that paper that basically says this, how we do papers from now on. Here's the website. Here's where you upload stuff.

Let me know if things are broken. And then we can finally just migrate ourselves off of the always publishing on through ISO, which I think will be great. Yeah. But yeah, that's basically everything I'm doing with the C committee. I want to have the discussion for just a moment

to bring you a word from our sponsor. As C++ coders, I think you can say we've gotten used to waiting. Waiting for code to be compiled, tested, and even analyzed. My friends at Incredibuild have been working decades to help developers like you and I code more and wait less.

Because expert developers don't wait. With Incredibuild's acceleration platform, I've easily gotten up to 10x speedup on real-world projects right out of the box. What I like most is how easy it is to use. Their virtualized distributed processing technology turbocharges product development with just a lightweight IncrediBuild agent. No need to install any build tools or source code, turning every host in your network into a supercomputer. It radically shortens compute times for a huge scope of applications, compilations, testing, graphics, and much more.

It's like having a bunch more HPCs and developers without adding a bunch more HPCs or developers. Go to incredibuild.com slash cppcast to start your free trial today. That's incredibuild.com slash cppcast to start your free trial today. That's a lot, bud. To bring it back to C++,

I know when you were on in November, we talked about the C++ and C working group. I don't remember what you called it, study group. How's that been going, the interaction? Yeah, the liaison group. It's actually been pretty positive. So Aaron Bauman's been chairing that one and holding the reins on that one.

So they're going through a lot of different papers, right? So they're talking about assert. They're talking about, you know, make sure lambdas are in sync. I think the biggest topic now is actually something that actually appeared in the latest mailing, the multidimensional subscript operator. So that one allows you to basically define

a subscript operator that takes multiple arguments, right? So basically they just, instead of restricting it to one argument, you can pass in zero to many, right? It's variatic. And that generated a little bit of liaison discussion where people were kind of, kind of the C people were a little bit grumbly

that we were taking space from the C arrays in that, you know, we were only, we were defining this new syntax that had this idea that you could pass multiple arguments to arrays. And so that generated a little bit of grumble. And so some papers might show up there for the liaison group. But the liaison group has also been tackling other issues in C and C++. So secure clear, I think, was talked about a little bit in the liaison group, which is a function

that basically is supposed to securely clear a block of memory and a couple other things that were also discussed in the group. And I think it's going pretty well. Oh, one of the other things that I actually wrote a blog post about was the LFDEF and LFNDEF, the preprocessor directives. So that was approved for C last meeting, which I'm super stoked about. I'm so glad that we finally plugged that hole. So if you've ever used this preprocessor, right, and you've typed in ifdef and you've done something, then you want to type LFDEF and you want to type something.

That LFDEF is illegal. You can't write that because it's not part of the grammar. It was never part of the grammar, right? So though it's like a a natural thing that you would just expect to work it doesn't um so c last meeting plug that hole right and i and i wrote how um in the blog post and you can read the blog post i'll just give a quick summary um i basically wrote how we were we were kind of doing the the thing that we often do in in the committee in c and c plus plus where we're like this is a nice feature but you can just write l if and then defined and then the thing and yeah right so so why do we have to introduce this new these new tokens and these new preprocess things we don't need it we can do the other way in fact if we if we were being consistent

we would delete if def and just have if defined because that's more powerful, right? And we got on that bender for a little bit. But one of the things that actually makes, I think, LF-def and LF-def fascinating is that this is one of those things that, like, it's very simple, and so you think most people would be like, why would you care about it? But it turns out a lot of people care. In fact, we got an email from a senior embedded developer

who's been at his job for well over a decade and a half who's like, yes, please put this in. Like, I am sick of running into this problem. Please put it in. Like, if you can, do anything to make sure that this makes it into the standard. Do it. And so we got a bunch of emails like that.

And so it was like oh okay this is this is a kind of a win for us right like you know so even though it seems like something like it would be better if it would help like heck it would be better if we deleted if def and just went with if defined um this is one of those things where it's like okay well we have if def and it saves people some time maybe it's actually worth having the feature in you know the language um and so that actually ended up turning the tides of the discussion and making it so that it was overwhelming that there was overwhelming support for it um and i think it was and it is one of those things where i was like it it's it's it often feels like when we're

standardizing stuff we're like detached from the community and we were never beholden to anyone and we're just like you know big huge, super crazy theoretical standards people that don't think about other people. But it's actually important that you do reach out to us because we are grounded by what you say. If a bunch of senior embedded developers reach out to us and say, yes, please put it in, that's a very strong rule to do the right thing. And so having that kind of support is actually pretty important, right? So I guess there's just a little bit of propaganda to say, email your friendly, you know, proposal author if you're, you know, you're a stake, like, you are a stakeholder in this, right? You ultimately end up working with the C standard, right? So, like, yeah, some of us do a lot of work to put the proposals out and do the work, right?

But, like, even just a small email, even just a small amount of user feedback does turn the tides for good. So, you know, I think that's kind of a good thing that came out of that situation, that that user feedback does, there is a connection between the committee and the end user, right? It's not just a committee sitting in some lofty tower being like, all right, I think today is the day we're going to introduce some undefined behavior today. That's how we'll see how the peasants deal with that oh all right you know it's we're we're a little more rational than that i think so you know i think that's that would be a little bit better um but yeah so that also showed up in the in in both c and c++ and i think it also got approved for c++ as well so i'm sorry it made it through the

evolution group in c++ it got approved by the design group well. So I'm sorry, it made it through the evolution group in C++. It got approved by the design group. So now it has to go through the wording group. And this is also kind of why I like the C committee a little bit better. Once your paper gets approved, it's in, right? There's no like multi-tiered stages, you know, groups, you know,

go through the incubator first, then have a discussion, and then we'd have a vote and the plenary. And there's like, no, we take the paper. Is it good enough to accept right now? Yes. Okay. It's in.

No. Okay. You need to go back and work. Right. And it's very actionable feedback. It's a very direct way of working on stuff. You can't ever get lost between groups or something or not know what's going on. So I think in that way, it's nicer.

But it's also probably due to our size, right? Like we average 20, 25 people a meeting, 30 people a meeting. You can talk to everybody. You can have time during the meeting week to talk to everybody and you won't miss out. So, um, you know, I think that's, that's kind of a good thing. Yeah. Was there any concern that some of these things like lambdas and deferred and whatever are going to make the language no longer simple and easy to implement and the things that people like to say about C? Yeah, so there is some concern that there actually is there actually is a lot of concern that that these things are difficult. But I think that a lot of people have recognized

that we're already that for all the things that people say C is simple about C is actually not that simple. And also that C already has a lot of this, right? So like nested functions, our GC extension that's implemented by half people. Again, Borland has the double underscore closure keyword in there, right? There's a bunch of other like statement expressions and being able to decay those to closures and function pointers and stuff. We already have that stuff. People have been basically compensating for C for a very long time, right? And so a lot of people realize that, okay, so we're asking for this Lambda feature,

but it's not really any different from what we've been literally implementing in our compilers, except everybody does it differently with suddenly different semantics, with suddenly different bugs and broken things. So maybe it's better if we actually just standardize on something

that does a good job of it, that's been proven to do a good job from many other languages to get it right. Now, there's other things about lambdas that are pretty scary, right? So with the lambdas, there's the simple lambdas proposal, there's lambdas with closures, and then there's a level three, the boss level of lambdas,

which is lambdas with auto. So I worked on getting TypeFuf into C, and that's going to hopefully get in this year. But Jens Gustav has been working on getting auto into the language. And so that's auto for type deduction. But then he also proposed auto for lambda. So if you have a bunch of lambda parameters and you sprinkle them with auto, it looks like you'll be able to basically have templates, but by the backdoor. So you can't name the templates.

You can't name the types. You can't do anything with it, but it's kind of templates, right? And so what sees, apparently, what Yen's and other people in C are trying to do is they're basically trying to have templates, but without any of the type baggage, right? So, you know, you have these lambdas, these polymorphic lambdas that can do these things, that can kind of support type generic programming, but without introducing the entirety of the template system, right? So how do you mangle polymorphic lambda? Well, it's up to the compiler, right? The compiler can make a decision, right? So instead of enforcing a lot of these decisions that kind of came with the whole Turing complete

template system, they're hoping to just kind of have this one thing, this one polymorphic lambda thing that you can do that will kind of serve the purpose of what most of lambdas do. And I used it myself to I prototyped a vector. I prototyped a vector in C using polymorphic lambdas, and it's actually pretty amazing. So I can have a single

vec of int or vec of whatever structure, and I can ship that to these polymorphic lambdas that I basically have a bunch of them in the global namespace, like vec insert and vec whatever. And I don't have to make vec int insert, I don't have to make vec double insert, I don't have to duplicate the code at all. The polymorphic lambda will just do the same thing for all of them, right? So I can effectively have a decent container library, right? The thing that people have been yearning for for like 30 years and see,

you can have a decent container library without the templates, just using these polymorphic lambdas and stuff, right? So it's actually pretty exciting. I hope that people do look into it a little bit more. Right now, what people have to do is they have to do crazy amounts of macro generic programming

and it's horrible and a lot of people hate it. But I think that that this actually has some potential for like really giving people like a very good way of having reusable code and generic code and c that actually scales up to to some degree right and again we're not you know uh lambdas you know they're not real function things right so you they don't have like mangling you don't have have to worry about how I put them in my binary. It's all up to the compiler, and you can't observe it anyway. So it feels like

we're getting a lot of the benefits of templates in a C-ish way that doesn't allow the whole template system to come in and wreak havoc on what C's identity is supposed to be, right? But even if we don't get polymorphic lambdas, just getting simple lambdas

where you can name parameters normally and it decays to a function pointer and you can size of it and you can set to a void star and pass it as the void star argument to a callback and do all that shenanigans, I think is already top notch. So I'm actually happy.

I'm kind of happy about the direction that that's going in. Yeah. Awesome. Yeah, sounds exciting. Well, uh, we're starting to run low on time.

Uh, a lot of interesting stuff is happening in the C committee, but I know one thing you announced on your blog that we definitely want to talk about is, uh, that you announced you're working on a new conference. Is that right? Yes,

I am working on a new conference. Um, we, I've actually been working on it really, really hard. Um, we've got sponsors, we've got music,

we've got, uh We've got artists working. Yeah, music. Because, again, it's going to be an online conference, so we actually have our own music and stuff like that, and people are working on that. We have artists working around the clock. So this is slightly privileged information that seems to be CAC exclusive. But it's unfortunately not the happiest of news

because we are going to be postponing the conference I think until October 2022 the original goal was to have it October 2021 and that's what we're shooting for but we that was that's like that's a hyper aggressive timeline and I mean we've been working on it for like since what since December of last year so you're hoping for an in-person conference is that one reason why no no no not an interesting conference no no i mean we don't have the resources for that just quite yet um but we we realized that if we held an online an online conference especially our inaugural conference um that we have so many ideas for things we want to

do that we would kind of run ourselves into the ground preparing for it by uh uh for october 2021 right and even though it sounds like a very far time away um and even though we have sponsors who have who signed up and many thanks to them and and we have many trainers and speakers some some really high hitting and and huge hitting classes um that i was really excited about personally um i think that it's that that shepherd and and all of us are kind of making the right call to delay it a little bit because i think like i think the best way to capture it is that we have not stopped having ideas for things to do since December.

And we have been pursuing every single one of them, and they're all turning out great. And we're kind of a little bit in trepidation that we will end up in a situation where we have all these great ideas and we don't present it as best as we can, especially for our first conference. And so I think Shepard and the rest of Shepard's Oasis is definitely making the right call saying that it's probably a good idea to postpone it until October 2022, when we can definitely do it way better than we are right now.

And so it's going to be basically postponed to October 22, which is sad because we just settled on the date, October 2021, like a month and a half ago or so. So we were excited. I had the submission system ready to go. I coded it myself, and actually I coded it in Rust, which was pretty cool. Don't tell NC programmers that I used C++ and C it was great but you know

I was actually really excited about the whole thing but I do think I agree with them in that we would do a much better job I think if we if we take our time and just definitely ship it out the door in 2022 rather than 2021

plus I mean people are going through the vaccination. Certain parts of the world are still not fully there yet. Other people are still trying to figure it out. I think by October, we'd have a lot of it figured out. But at the same time, I think a lot of people would have a lot of online exhaustion, constantly having to be at things online and stuff like that. I think that waiting the year is also just a good thing for that as well, because I think a lot of people,

I know that this is good, especially because we, we covered live captioning. We already had live captions scoped out and covered. We had a bunch of other like accessibility features scoped out and covered. So I think a lot of the people who are, who have disability will be kind of disappointed that we're pushing it

back to 2022, but I think our commerce will be even better for that, and we're going to have even more features for them and more ways for them to participate as well, which is another decision factoring into this for us, because we want to make sure that it's an accessible commerce. We want to do it a little bit differently than everybody else.

Obviously, we're trying to pay our speakers as well so that they actually feel like they're not just showing up for clout, but they're actually showing up because we value their time. You're you're just for the exposure yeah i've seen this on like uh clients from hell or whatever you know people die from exposure right yeah exactly right but so we we have a lot of like we have a lot of like things that we're trying to execute on um and we just think it would be a much better conference if we wait until 2022, right? Thankfully, cash and everything wasn't really that much of a concern.

We were doing very good on all that stuff. So I think hopefully the sponsors will still be interested in a 2022 conference. Hopefully, they'll kind of carry that energy of supporting a new conference that focuses on an inclusive environment that's welcoming to everybody, that gives you the tools and everything that you need to learn and has great trainings and everything else so i'm hoping that that is going to be good but yeah i personally i mean i'm still a little bit disappointed right i wanted to hit hard with a 2021 conference but uh you know the the pragmatic decision should be should be made you know so yeah okay well we'll definitely have to talk more about it as we do get closer to that uh october 2022 date then okay yeah definitely um i'm gonna be going

on like a you know i was actually already planning to do like a whirlwind tour of like talking at a bunch of yeah uh places to to advertise the conference but now i mean for now i mean i guess i can still go to those places and just kind of talk about all the c and c++ stuff i'm doing which i'm actually i've somewhat secured a this little bit hush-hush, but I've somewhat secured a deal to start working on some. This is a public podcast, just to make sure. Yeah, no, no, no. Everything I'm saying, it can be said in public, but I'm going to be, people are going to start noticing some commits coming from places that are going to be improving various things related to freestanding and related to embedded development that haven't quite been done before. And I've been talking big game about,

I can write a vector in two weeks and stuff like that. I think people are going to start seeing the fruits of that appearing in places that they can actually publicly access and very soon. But I can't say more. It's all hush-hush. But you're going to start seeing some serious improvements and embedded developers are going to start seeing things that that people um like me and other people are taking their concerns seriously and that you know all the

the hooting and hollering they've been doing uh has not been in vain um and so you know again you you heard it here first so you know make sure you listen to CP Casting and get the exclusive deets only here with Rob and Jason. Alright, well I think that's a great note to end it on. Thanks so much for coming on again today, Jean-Huid. Absolutely my pleasure. That was great, Austin, thank you. Thanks so much for listening in as we

chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on 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 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 is provided by podcastthemes.com.