CppCast - Boost, The Beman Project and Beyond

Episode Date: June 14, 2024

Zach Laine joins Phil and Timur. Zach talks to us about the Boost collection of libraries, his contributions to it, a little of its history and where it's going, and a new project that aims to get back to Boost's original roots. News Timing vulnerability in Kyber due to compiler optimization pass JUCE 8 released C++ Under the Sea - new conference in The Netherlands Links Boost

Episode 384 of CppCast, with guest Zach Lane, recorded 7th of June 2024. In this episode, we talk about a Clang optimization that makes cryptographic algorithms insecure, a new version of the Juice framework, and a new C++ conference. Then we are joined by Zach Lane. Zach talks to us about news from the world of Boost and beyond. Welcome to episode 384 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dummler, joined by my co-host, Phil Nash. Phil, how are you doing today? I'm all right, T phil how are you doing today i'm all right i'm a hating i'm all right um except

that i'm a bit tired um i just had uh a trip um i just came back from c++ russia which is a c++ conference in moscow um and i was giving the closing keynote there um the conference itself was pretty great it's uh it was very well organized very high quality content as. As you know, I'm actually from Russia. I was born there. I have friends and family there. So that conference has always been very special for me. It's a very special thing to talk there. But it's actually very difficult to get there right now

because there are no flights from Europe to Russia. There are no trains from Europe to Russia. I live in Finland and the border between Finland and Russia is just completely closed. So you have to kind of travel around and it's very, very tedious. It took me like 24 hours just to get there at like one way, even though it's quite close geographically. So I'm quite shattered from the, from the whole trip. I'm still, still recovering, but the conference itself was, was amazing. So that was, that was great. That was totally worth the trip. Congratulations on the keynote.

Yeah. Yeah. That was fun. Um, it was the first time i gave a keynote in russian actually that was that was fun as well it was normally like i normally i talk in english but yeah that was that was fun uh what about you phil any any recent conference trips or other stuff you you just had a conference that you organized didn't you how did that go yeah so swift craft so not c++ but uh i did mention it in the last two episodes as it happened it was just coming up perpetually and uh it ran a couple of weeks ago went really well actually but much smaller than we originally expected but everyone said you know what a great time they had and they're looking forward to the next one

and that's really all you can ask for a first time conference so uh yeah i'm pretty pretty pleased with that. I'm a bit tired as well. It probably didn't take you quite as long to get there, right? Where is the conference? That's in Folkestone. It's the same venue that we have for C++ on C. Oh, is it the same venue?

Yeah, that's a beautiful venue. Yeah, yeah, that really was part of it. All right, cool. So at the top of every episode, we'd like to read a piece of feedback. Our last episode with Sean Baxter actually generated a lot of discussion. We got lots of emails. There were lots of comments on Reddit and elsewhere.

All kinds of comments. Some people are agreeing with Sean and they say like, this stuff is great. Like the circle stuff, the Brochaker stuff. Some are challenging his approach. Some are pointing out things that we should have discussed or but didn't discuss or you know that some people thought were just outright wrong you know very very interesting comments thanks to everybody for writing those sending us those i don't think we will be able to respond to every email there's

quite a few but i do want to read out one email by George Ford. George writes, I loved the episode. I was wondering why Circle wasn't included in the original series of C++ successors. I've played with Circle in Compile Explorer and it's fairly straightforward and promising. I think this was the most interrogation I've ever heard Timur get involved in. Way to push him because this is a very different approach to super sars memory safety especially considering how many times he mentioned implementing lifetime and borrower checking rules using that four-letter word rust lol great job guys um well uh thanks george for your feedback i can explain why my interrogation of sean was so harsh i actually um was very sleep deprived i did the episode on something like two hours of sleep.

And generally, I'm kind of chronically sleep deprived right now because we have a little baby here at home. So I was very grumpy when we recorded that episode. So I think I was maybe a little bit more rough with Sean than I would normally have been. But it seems like he didn't take it personally and the episode still turned out okay. What do you think, think phil well i think we should make sure that you are sleep deprived for every episode well as it so happens i'm again sleep deprived for this one not quite

as badly but yeah i just came back from from this trip from russia and like have not slept very much last night so um let's see how today is gonna to go. Yeah, so we'd like to hear your thoughts about the show. You can always reach out to us on xmastered on LinkedIn or email us at feedback at cppcast.com. Joining us today is Zach Lane. Zach Lane has been using C++ in the industry for 20 years, focusing on data visualization, numeric computing, games, generic programming, and good library design. He is the author of multiple Boost libraries and a member of the ISO C++ Standard Committee. Zach, welcome to the show.

Hey guys, thanks for having me. So I've seen your bio around in a few different places now, and like many of us, you have like a variation of the same bio everywhere what i've noticed is that you know number of years in c++ industry it's a different number each time and yeah on the face of it that makes sense you know it sort of goes up one every year you would hope except i think it actually goes down as well so really so let's just clear this up once and through when when did you start using C++ in industry? So the first professional job I had doing C++ was in December of 2002.

That's when I got hired my first job. So 22 years. Yeah, I was still a student. And so for that six months or so until when I graduated in May, I was a student. And then I got hired full time at the same place. Yeah. So, yeah, 22 years. Yeah.

That's crazy. It's been a long time. Well, actually, no. So I guess, you know, 21 and a half. Yeah. I need to put a 1.5 in that bio. Yeah. Right.

Okay. We just put from 2002. Then it's always correct. Yeah. Yeah. Yeah. Yeah, yeah, yeah. Yeah, and that's the thing is I think like, you know, when you've got like eight years in your bio,

you're like, well, I really want that to be a nine. Like it makes me sound more professional or knowledgeable or something. Once it's over 20, you're like, you know, more than 20 is probably what I'm going to leave it at kind of forever. Yeah. Yeah.

Well, Zach, we'll get more into the stuff on your bio in just a few minutes but first we have a couple of news articles to talk about feel free to comment on any of these sure so we got three news articles today the first one is from pqshield.com which is a company doing cryptography stuff and that article talks about um an interesting case where the Clang optimizer took a branchless algorithm and optimized it in a way that adds a branch. Which sounds like, okay, optimizers do all kinds of stuff. Like, why not? But this actually happened in the reference implementation of Kyber, which is an important quantum-safe cryptographic algorithm. And why is that really bad?

Well, cryptographic algorithms are deliberately implemented with branchless code right because instead of like if else wild switch whatever you you have like bit masks and similar things to make sure that you always execute the same amount of instructions every time you like perform the algorithm because uh you can't have an algorithm where the observable behavior and that includes like how long it takes right depends on like your secret data like passwords or whatever otherwise you can extract the secret data which is exactly what you're not supposed to be able to do so so you can't have control flow that depends on on that on the secret data right you you always have to do everything branchless

with like bitmasks and stuff and so the problem is that like clang uh basically took this bitmask and reasoned about oh well this bitmask is always like either all zeros or all ones and so the masked value is always either zero or a constant and so i can just turn it into a branch instead because in x86 a branch is heuristically like faster right so it did that but then a malicious attacker can actually then basically run the algorithm with like you know many times and just time it and then just from that timing actually extract the password which is like really bad and so uh it took a lot of effort to fix actually the article goes into um a lot of detail like how they like what the actual problem is actually shows the exact code it's of detail, like how they, like what the actual problem is,

actually shows the exact code. It's actually quite cool, quite detailed. They had to basically rewrite the code to kind of confuse Clang. So it doesn't actually do that optimization anymore. But yeah, it's kind of really cool and interesting and also really scary. I also, I think it mentioned that

this is not the first time something like this happens. So optimizers, you know, use heuristics to make things fast, but sometimes that's not actually what you want. Well, but so, you know, I saw this article when it came out. I think someone linked it on Reddit or something. And, you know, I'm kind of nonplussed by this article. So I'm writing to an abstract machine, and then the abstract machine didn't do this exact thing that I wanted

that is below the level of the abstract machine. And so I wrote a whole article about it. That seems like a weird choice to me. Like, I understand that it's a problem for you and your implementation, but like C++ doesn't give you guarantees. Like if you write code that doesn't have branches in it, the object code that is generated will look like this and not have branches in it. Like that's not a guarantee that you're given for the language, right? You get the guarantee from writing assembly yourself, but you don't get the guarantee from language. The assembly that you get is a function of some implementation details

that have nothing to do with C++ as a standard, right? So I don't think it was a criticism of the C++ language at all. I think it was a criticism of, or a comment on like the compiler and like kind of compilers shouldn't be doing this with real world code. I don't think it's very much about like the language.

The compiler is implementing a standard, right? It's implementing the language that you're using. That's kind of my point is that, and also like, you know, I only skimmed like the article itself. I was mostly responding to the hue and cry from the Reddit community or people like, I can't believe the compiler is doing this.

I'm like, I can, that's what the abstract machine does, right? That's the whole point. Well, I actually stumbled doing this i'm like i can that's what the abstract machine does right that's that's the whole point well i actually stumbled upon this uh from a completely different blog that i'm reading it's a german language blog it's like called feifers blog and feifer is like a famous german like it security guy who has like a very cynical uh like he has this blog blog like in german where he just very cynically comments on everything that's happening in the world and occasionally comments on like it security stuff and and he just posted it there saying oh this is like really bad and like like you know compilers i'm like doing this this really bad stuff and that shouldn't be happening from a perspective of a security person and i clicked

on it and then that's how i stumbled on this article and then later i realized oh it's also being discussed on reddit yeah but from a perspective of like a security expert, like you don't really care what the standard says. You just like, that's really bad from their perspective, right? Well, yeah, no, it's really frustrating. I get that. But like saying that the compiler is doing something nefarious or like this is a poor quality implementation

because it did this to my code is just, I think it's just wrong. I don't think they did that. Like they didn't say the, like, like okay i need to read the article again but i don't i don't even think they they filed a compiler bug they didn't say the compiler is doing something broken they they actually fixed it by changing their own code yeah they just say it's unfortunate that compilers are doing that right it's clear why the compiler is doing it it's like it has a heuristic that says it's going to be faster this way. So it actually is

the correct implementation if you want performance. So, yeah. I mean, I only skimmed the article as well, so I'm also qualified to wade in. I got the impression

that, I mean, it was partly just a forensic story. You know, it's interesting to read about what's actually going on here, but also partly just raising awareness that this is the sort that, I mean, it was partly just a forensic story. It's interesting to read about what's actually going on here, but also partly just raising awareness that this is the sort of thing that does happen, and there are some cases where we actually need to pay attention to that, particularly when security is involved.

So I don't think the PQ Shield people were actually criticizing the compiler. This German blogger, whose blog I was reading when I stumbled this from, he was criticizing it, but he's a very kind of cynical security expert kind of guy. So I guess, anyway, we have other news items. The juice framework, which is something that I actually happened to have worked on like a decade ago or something.

That was fun. It's a kind of cross-platform application framework. It's kind of similar to Qt or WX widgets or something like that. Except it's also very popular for audio and music software in particular. It's kind of not limited to that, but it's very successful in that industry.

So that is getting a major update. Juice 8 is now available as a preview. What's new in Juice 8? It has a WebView UI. So in addition to writing uis in c++ the way you could always do it in juice you can now do it uh in in your like web view thing of your choice and that works they improved unicode support um including consistent text rendering on all platforms which is surprisingly hard i remember this from like using juice for my

own like apps um that like the fonts always look a little bit different on Windows, on Mac, on Linux. So they fixed that, apparently. It took months of research and more than two person years of development time just to fix the font rendering. That's, I think, interesting. And yeah, they have a few other improvements there,

but it's a major release. So I thought it was newsworthy. It's a very interesting framework that's been around for a while and used in a lot of software that's out there and making money and being used. Zach, you used to be on SG16, the Unicode study group. Does it sound to you very far-fetched that it took two-person years of development to fix this issue in juice?

No, not at all. Unicode is very difficult to get right. So, you know, like I'm not that involved in SG16 these days, but, you know, SG16 was like, you know, full of all these experts who had used Unicode for many things, experts about different parts of C++,

they're all committee members. And we have a guy that started showing up to the meeting who was a liaison from the Unicode foundation itself or the Unicode standards body. I don't know if it's called a foundation. And the number of times when we would be talking past each other and talking in circles because people just didn't understand kind of low-level assumptions that exist in Unicode because it's so fiddly and there's so many crazy details. And, you know, ultimately when you take every single natural language that's ever been spoken

and say like, yeah, we're going to write a library that does that, it's going to be difficult, right? And so, yeah, like everything related to Unicode always gets very thorny and there's all kinds of crazy exceptions and it's very easy to get subtle things wrong. I wish there was a, I don't know, something like a thick book that says, you know, this is how text works in software. And I could just read it and then I would understand it because I mean, I think the Unicode standard is intended to be that. Oh, okay. And, and the,

the only problem is that, um, you know, there's some, there's some sort of like – I guess you'd call them something like logistical problems with the Unicode standard. Like they use the word character in an overloaded way. Like the word character can mean code point. It can mean like a char. It can mean a bunch of things different. It can mean a grapheme cluster at some times. But I don't know if anybody knows what these things mean. So the point is that – yeah, yeah.

So there's like um based on context character might be one thing or another and then um but there's there's like deeper problems which is like okay so there's this bag of algorithms that comes with unicode and um i'm supposed to apply them in different places and then there's just some invariance across the algorithms like if you use this algorithm the the data the results can be used with this other algorithm. But if you use this slightly different algorithm, like I'm thinking of normalization here, you normalize stuff slightly differently, then this other algorithm doesn't work

with that normalization form, so you have to renormalize if you want to call that other algorithm. Some algorithms don't care about normalization. So it's like this body of knowledge you have to slowly accumulate over time for you to be able to even use. If you had an off- off the shelf Unicode implementation that you could use,

knowing when to employ the different algorithms from that implementation is not trivial. So it's all complicated. It's not like we need to normalize the normalization. Yeah. We need to have some kind of metanormalization in order to get this working. And I mean,

the way that we were thinking of doing this with the Unicicode working group was like i think a lot of people would like to have some kind of type that would be a unicode where string and it would template parameters that tell you what normalization normalization form things are in so that if you try to use the wrong one at the wrong time you at least get ill-formed code all right so this is a fascinating topic but we're not doing an episode about Unicode, so I suggest you don't fall into this rabbit hole right now. We can maybe do one another time. I'm sure that's going to be fascinating. But there are other things we want to talk to you about. So I'm just going to briefly mention the last news item for today, which is there is a new

C++ conference in the world, which is always a very exciting exciting thing so it's called c++ under the sea which is obviously a pun on a pun on phil's conference c++ on c which is in the uk but this new one is in the netherlands it's happening on 11th of october 2024 in breda in the netherlands um there's a pre-conference day on the 10th it's one day uh two tracks conference early bird tickets are 300 euros so it's not a huge amount of money comparedtracks conference. Early bird tickets are 300 euros. So it's not a huge amount of money compared to things like, you know, CBPCon or something. So, you know, if you're in Europe and you don't want to spend too much money

on a ticket for an international SuperSus conference, you know, that sounds like a pretty good deal. Jason Turner is giving a keynote. The submission deadline is the 12th of June, which actually, as I just realized, will have passed by the time that this episode airs. So if you want to submit a talk to this conference, it sucks to be you.

It's too late. But yeah, I hope that there's going to be a great program. I'm pretty sure there will be. There's great people involved in this. And yeah, so that's very exciting. I unfortunately don't think I will be able to make it, but maybe you will, Phil. You're not that far away, are you?

I will be there. That's really cool. Yeah, it's cool. And yeah, just to be clear, they did approach me before they went live with this name to get my permission. They didn't have to do, but it was nice that they did approach me before they went live with this name to get my permission. They didn't have to do it, but it was nice that they did that. Yeah, that was nice.

All right. So are we going to have more conferences with related titles now? Is there anything else you can come up with here? C++ through C, which happens, everyone's swimming. Oh, yeah. With kind of deep C. You could have one on a cruise ship and like out on the sea or something.

Anyway, but we can cut that part out. At sea. Sea was us at sea. We should totally have a conference on the cruise ship. Anyway, so those are all the news articles we have for this week. So we can now proceed to our main topic for today, which is our interview with our guest, Zach Lane.

Zach, thank you so much again for taking the time to be our guest today. Yeah, it's great to be here. So I think one of the things that you have been most involved in when it comes to C++ is the Boost community, right? You've been part of that for quite a while. You've actually authored multiple Boost libraries, right? So can you just remind us what they are and more broadly what your role is in the Boost community?

Yeah, so we'll take the second part first. So I was introduced to Boost at my very first job I ever had. I think I'd been on the job for like a week and someone said, do you know what Boost is? I'm like, no, what's that? And I saw it and I'm like, how did I not know about this? This is full of so many amazing things.

So I started kind of lurking on the Boost list, keeping up with what was going on in the Boost mailing list from then. And, you know, I had like some kind of interaction over time. And then eventually I had a library I thought I wanted to submit for Boost. And so I've been active as a Boost contributor since I think 2016, and maybe 2017, something like that. And I'm also on the Boost Foundation board, which is not really related directly to the Boost project. It's sort of like the legal entity that pays the bills for web hosting and stuff like that. Although now we're going to be turning the web hosting over to C++ Alliance.

But there's a few other bills that we have to pay, and that's the only reason the organization exists. Partly that's necessary because all the resources that Boost used were donated by volunteers before, and then one by one they were like, why are we doing this? Get rid of these guys. They're sucking up all our resources, and so now we have to pay for things ourselves. That foundation also is involved in putting on c++ now so um so that's kind of my involvement with the organization and as far as boost authorship goes my first library was a

thing called yap which is a an expression template library for c++ it's kind of an updated version of boost proto and um that was written in the c++ 17 and 14 standards, I believe. Then the next library I did was a thing called STL interfaces, and that is designed to make it easier for you to write things that are STL compatible. So the main one that everybody uses, I think, the most is the iterator facade called iterator interface. And I'm currently trying to standardize that.

I'm hoping to land that in C++ 26. So there's papers in flight for that. We're kind of at the point of moving that into wording review. The design is pretty stable at this point. And then the latest library, which has been accepted through the Boost review, but is not yet in part of a Boost release. I'm not sure if I'm going to make the next release because I've just kind of run out of steam working on it, but I'll probably make the release after that.

There's a thing called Boost Parser, and it's kind of an updated Boost Spirit. So the Boost Spirit framework is showing its age because it was written in like the, you know, 03 standard. And there's an updated version that was written in more modern c++ but it's kind of under document a lot of people don't even know it exists called spirit x3 and i want to take like the best versions of the library like spirit x2 or sorry not x2 spirit 2 and spirit x3 both had very implement different implementation strategies and implement different versions of c++ and they're kind of radically different but at the core they have the same kind of domain-specific embedded language D cell

operators, like, you know, right shift operator to mean like a sequence operation between two things you're parsing, and so on. So I tried to keep all of that. And both those libraries are super fun to work with. So I wanted to make something that was really easy to use, really fun. And it was a lot of fun to work on and there's a lot of interesting features. And the thing that I love about the Boost process is Boost is fraught in a lot of ways, right? It's not the most welcoming environment. It's not like it's done on a mailing list.

It's kind of antiquated at this point. But one thing that it absolutely shines at is if you do a Boost review, you're going to get incredibly useful technical feedback in a like you know concentrated form right so like if you have a library and you put it up on github every once in a while someone will stop by and say like hey this thing is broken could you fix it or hey could you add this feature if you take all you know let's say you do that for two years and

you have a reasonable number of users you take that hundred weeks worth of of input that you've got for over that two years, you're going to get that from the boost mailing list review in like two and a half weeks, right? And so you get this really intense thing of like, I'm questioning all my life choices and like, is this going to work? And then, you know, there's a combination of like,

you know, some of it sows doubt and then some of it is just like, absolutely. Like, why didn't I think of that? That's a great idea. Right. And then some things are kind of in the middle. And some things are like, did you try it this way? No, I didn't. Let me go investigate that.

And so you get like a really great overview if the boost, if the review happens with a good level of involvement, you get a really good amount of feedback. And so, you know, I've been through the review process four times. One of the libraries was a Unicode thing called Boost Text that failed the review. And got on it like i even though it was a rejection i am the library was way better for being rejected than it would have been if i had just put it up on youtube or not youtube put it up on um github rather and let people just you know whack at it right so it's you know i don't know of any other place that you can get feedback like that on an open source project that is so constructive and so useful in such a concentrated period of time. It just doesn't exist anywhere

else. So, you know, this is the thing where I, as a committee member, I've tried to get people to, you know, they have some idea for some library XYZ, right? And I'm like, oh, XYZ seems interesting. How many users do you have? They're like, you know, me and my dog know me and my dog right so i'm like okay well maybe you should have more users and and a good way to do that would be you know take it to boost and then like submit as a boost library and you get all this incredible feedback from these people that are like you're bad and you should feel bad to um this is a great library and everything in between and and the result is always something that comes out better but those those reviews that are along the lines of you're bad and you should feel bad really turn off a lot of people and they don't want to participate in that process.

And I kind of understand that. But at the same time, I mean, if you can stomach some, you know, disconsoling reviews, like the results are pretty spectacular. Yeah, there was a comment that people used to make a couple of years ago. I don't know if they still do. A little bit snarky, but saying that it's easier now to get a library into the standard than into Boost. I think that's objectively true. Yeah, I mean, it's crazy, but it's true.

No judgment either way. It's an interesting data point. And, you know, there's a bunch of people on the Boost list who are like like this is exactly what's wrong with c++ and what's wrong with the the standard and i don't know if i i buy that but there is a definite gap between the difficulty of getting a boost library um reviewed and accepted versus stuff in the standard and actually so this is something that that you know we had talked about discussing maybe, but – okay, so I should back up. The original foundation of Boost was a guy named Beman Dawes who was a committee member from the pre-98 days. He passed away unfortunately a few years back right before COVID.

And he was really like a really well-liked guy and really technically savvy. And he did all kinds of great stuff for Boost and for the committee. He was a leader of one of the rooms in the committee. He's the guy behind Boost file system and then ultimately standard file system. And so Beeman's idea was, you know, we have all these libraries that are kind of coming into the review process or the review process, the standardization process. This is, again, in the pre-98 days. And he's like, what we really need is something that we can use to kind of road test these libraries. Get them out in lots of hands.

Get them widely used. Figure out what's wrong with them. Retool them. Reshape them. Figure out the best possible version of whatever library that is, and then standardize that. So that was his idea for Boost. And that's exactly what Boost did for its first few years.

And I want to say something like 14 of the first 17 libraries added to NCPlus was 11 were straight out of Boost. Some was slight modifications. Some just adopted wholesale. There was a bunch that were... Like File System and Annie and Optional and Variant and I think SharePointer. Yeah, yeah, quite a lot of them.

Well, all of those that you mentioned, except for SharePointer, came after 11. But yeah, 11 was like a ton of stuff, including SharePointer. Unique Putter was an invention that was added that did not come from Boost because you couldn't do it in Boost. Anyway, so the idea was,

let's do this. That's the Boost project. And then people would add stuff and then it would just be part of the review process, but they didn't really intend to standardize it. And some of the stuff that's been added, like no one really wants to standardize it, including the person who submitted it.

That's not the point, right? And that's fine. There's nothing wrong with that. It's not a criticism. But the point is, it, that's not the point, right? And that's fine. There's nothing wrong with that. It's not a criticism. But the point is, it has really lost that original purpose that this is where you go to get stuff widely used so you can figure out how to standardize the best, right?

Yeah. One of the biggest libraries that were standardized more recently, like Rangers, I think, basically Eric just put it on GitHub, right? It never went through that process. And now it's in the standard. And I think all of the more recent synchronization stuff is like that.

I think actually a lot of the more recent standard library stuff kind of never went through Boost, I think. Yeah. Oh, absolutely. It's very rare. In fact, like every once in a while, Peter Dimoff will either propose or someone will propose one of his libraries from Boost. And I have explicitly put SQL interfaces into Boost because I wanted to standardize that iterator interface

and I wanted people to use it first. But with the exception of those two people, I don't think anyone is using it for that purpose. And me and Peter are not using it for that purpose, like very often. Right. So, so the point is that right now you can have your cool idea for library XYZ. You can bring it to the committee. We can talk about it a bunch and then we put it in and we don't know how many people have used it. We don't know how broadly it's, it's gotten used from the people that are using it. And we don't know what the corners are that we're going to be regretting

in a year or two after it gets deployed. And that's a problem, right? So me and a bunch of other people that have been involved in Boost and been involved in C++ Now and been involved in the committee at C++ Now, so that we had this conference just this year,

but the one before that, a bunch of us got talking about it would be nice to have like a refocus of Boost back to that original mission. And then some people were like, well, you know, like why try to turn that chip, right? Like it's hard to steer something. It already, Boost does what Boost does and that's great, right? It does its thing and it does really well. Why not have a new thing that takes the old mission of boost and does that. So that's, that's the thing we came up with.

And someone says, so we name it after B minute. So we call it project B minute. And so it's very early days yet. There's like nothing there yet, but the idea is that we want to have a set of hopefully like, you know, using like a VC package and or a Conan set of hopefully like, you know, using like a VC package and or a Kona and some kind of, you know,

package managed loose confederation of things. And then Project Beeman is just an index of those things. And those things are each a library proposal with an actual paper and a paper number. That's how you get into the project. You have a paper number and you have a library. And the actual implementation is the thing that people check out and use and so as a user if you want to point to this particular tag for one particular version number you can use this thing and have a stable version of it that's not moving up from under you you don't have to deal

with the the update cycle this is a this is a problem where boost has been the victim of its own success somewhat where when you have a new version of boost a lot of people don't want to upgrade to it because there's probably source and semantic changes in that new version of boost somewhere if you're using enough boost libraries that that's going to bite you so the migration story is difficult so the idea is to get people to actually use it in real production code give them a way to to have a specific version tag version they want to use and try out that is stable. And then other people can live ahead if they want to. And then the combination of those two things, we're going to hopefully get more people to implement more libraries that go into the standard with good unit tests.

The documentation is nice to have, but it's not super important. The ability to look at the code, understand it, use it, and verify that it works via test and use cases, that is really important. And that's something that we're missing right now. A lot of times we'll have things go into the standard and then we realize, oops, like that part doesn't work and we thought it did. I shouldn't say go into the standard. That's an overstatement. We will have things make a certain amount of progress within the committee and then it gets caught. I've never seen anything that actually goes to the standard broken.

I shouldn't be representing it that way. But I have seen things get to, let's say, a plenary vote, which means it's been through all the individual rooms and now we're ready to merge it into the international standard, the draft international standard. And then we take a big vote of everyone in the committee and then someone's like hey someone noticed that this one part of it is probably not implementable and that happened like somewhat recently that there was an objection like that so yeah it was actually one a paper i was involved in that was uh in place vector which is exactly something that's really useful for like low latency real-time code which

is like a vector that doesn't allocate because like all the elements are inside the thing so it's like a small vector optimization but it's only that part no no heap allocations and then like well it's kind of highlighted a bit of a defect in the process because we had the paper basically written and there is an implementation and then i think uh library evolution said well why don't you just like slap constexpr onto everything exactly because that's what you kind of do and that's like we haven't really and that brings had that but like they said do that and then fine they voted it to the wording and then you know people noticed oh but like this

bit you can't actually like that's not implementable in constexpr land like like do you have an implementation and you were like well no like you just got told to add constexpr like by this other room like yeah that's not what we actually had an original proposal and they were like well like but that doesn't work and you know that came up in plenary so we had to actually retract the paper at that stage which yeah yeah and then I got like kind of busy with like contracts and I'm kind of not really participating in that paper all that much. So I don't know where that is currently. Yeah. And so, you know, that paper, so, you know, that paper isn't the only problem like this that has happened.

But the point is that like, if we had a part of the culture that if you want to slap context around something, the way you do that is you actually go and do the implementation and you have tests. And then you come back and say, yeah, we put context on it and it works and here it is and everyone can see it. And if that were part of the way we did business, then we wouldn't have these kind of problems. And so the idea is to make it easier for, number one, people to have a well-known place where the implementations live,

and number two, for people to get those implementations easily and use them, and then have an emphasis on good test coverage. I think that's awesome. So basically you're saying that if we vote any sizable library additions into the standard, we just have to have that implementation there that matches the paper that people can can work with or play with and that's there and that compiles and runs and passes the test i think that's great like i wouldn't i'm totally like if it means that like some stuff just doesn't get into the standard but then also like we get

less broken stuff i think overall that's a win so i think i'm already a fan of this the one time that breaks down is where it depends on language features that are being co-proposed or you know they've already been accepted into the standard whether or not in the working draft like they have a bit of concepts and ranges well ranges so here's the thing so ranges obviously heavily depends on concepts, but ranges also had an implementation where all of that stuff was emulated with horrible macros that like resolved to enable if under the hood,

and you don't really want to know how any of this works. Right. But like it did exist, right? As a proof of concept. Yeah. Yeah. And so that's the thing is

you might have an implementation of your library that only works with Clang or only works with EDG or only works with this one implementation because they're the ones who've implemented that thing yet. But hopefully we've got people implementing language features. And I mean, like the evolution room is actually very good about requiring people to do that. We have the exact same problem. Sorry to interrupt, but we have the exact same problem in the language side of things, right? Like we are voting language features in that don't have implementation

experience. And sometimes it's okay because it's quite obvious, but sometimes, you know, you discover things afterwards that don't quite work the way you expect them to. That's bad. That's probably even more bad for language features than it is for library features. Yeah, absolutely, because you're stuck with it. It's chiseled in stone at that

point, right? Like, you're just not getting rid of it. But so that's the thing is that, like, the evolution room is really good at saying, like, because you're stuck with it. It's chiseled in stone at that point, right? Like, you're just not getting rid of it. But so that's the thing is that, like, the Evolution Room is really good at saying, like, where's the implementation? Okay, you need to implement this before we're going to move forward with it, right? They're very good about doing that. At Library, we're not as good about that.

So that's why this thing, I think, is necessary for Library and less for the language standards, the language changes. I don't think, for example, we had an implementation for spaceship and um well that i think that's a few problems that were discovered there was implementation of part of it but then the the design changed out from under that implementation it wasn't revised i think that's what happened with that but i could be misremembering but yeah there was i think it was more the semantics were well understood and the implications of those semantics were not. And so the impact on the library was pretty non-obvious.

And then David Stone and Barry Resvin, like they went through and wrote a series of papers that said like, well, what happens if we actually apply this to existing stuff in the library? And what does it look like? And they, they were like, oh yeah, these aren't the semantics we want. So it wasn't a implementability or it wasn't that question. It was like, when we take this thing with the semantics that we have defined and that we actually use it in real code, do we like it or not? That was the problem with it.

So I think it was more a design bug than a than a um okay like a kind of specification bug or or like um you know something is uh you know ill-formed with the design where it doesn't work at all it was just like the design worked but it made uh semantics that i think a lot of people were like no no we don't want those semantics but i had the property that it changed the meaning of some existing code which is always a bit fraught yeah yeah that's um yeah you know so there's like i remember when we were talking about um no unique address i was saying well isn't this like an adl trap or not sorry not adl a uh abi trap um and um and i was people insisted like no because the implementer would have to write all the crazy

metaprogramming tricks to make this work but they're going to get exactly the same layout either way this just makes it easier for them to write it and then i heard about an abi break that happened in the wild with exactly this problem yeah um so you know i mean that is bad like i that's one thing that we should never have standardized, in my personal opinion. Like, that is bad. Like, we should not have standardized it as an attribute, for sure. I mean, I think it's great.

I think it works great. Okay, fine. Let's not get into that rabbit hole. So I will say, the one thing that we have not figured out at all with Project Beam in is is how do you do something like oh well i want to add this member function to string because that seems to be some people's hobby they want to add a million minute for the string i don't like it but that's what we do so if you want to do that like you essentially have to have some like i don't know project beaman thing that's like i went to gcc and it took string implementation i

cut and paste the whole damn thing in there and then i have a patch on top of that like i don't know what you can't really do that though because i think exactly a lot of the stuff especially like vector string those like really heavy kind of old standard library things like i think their implementations actually quite heavily used like compiler intrinsics and like compiler specific stuff so exactly like you couldn't even have a reference implementation of that stuff even if even if you had the you know 100 person years or however long it would take to like to implement like a reference implementation of like the standard library like that just wouldn't work on like the way boost does like it wouldn't be cross like cross compiler like that

yeah yeah i see where the problem is like that just doesn't work like that yeah and you know some people have some ideas of like oh well maybe i could refer to a certain standard library header and i could have a list of patches or maybe i could do the cut and paste thing i was talking about and say well this only works for gcc because like you said maybe it's using intrinsics and the other gcc headers and so on so there's not a good story for it yet that someone's come up with so if anyone has any ideas please um you know tell me because i don't know what the answer is all right um yeah okay so um we talked about boost and the committee a lot i'd like to like maybe take the discussion a little bit away from like what the committee is doing and more like towards like kind of using boost and like users that use

boost so so recently boost actually underwent quite a significant change i thought like you what the committee is doing and more like towards like kind of using boost and like users that use boost. So, so recently boost actually underwent quite a significant change. I thought like you dropped support for superstars 98 and 03 from like a lot of libraries, right? Do you know like what impact that had? Okay.

So this, that's a slight mischaracterization of what happened. So, so what we did was, so I should give you this bit of background. So the way that Boost works is it's essentially a confederation of different libraries, right? So every Boost library author has to go through this very rigorous review process. They have to address all the issues of the review that might have existed, and then their library goes in. And then after that, it's the wild west.

They do whatever the hell they want. It's kind of a weird peculiarity of the system, but you are the king of the castle if you're a Boost library author. Okay. So the idea is that if you want to support C++98, C++14, whichever particular version you want to support, then you just do that as a library author. No one's going to stop you.

And that was never changed. So particular libraries may or may not have lost support for C++ 98, but honestly, that was happening. Many, many individual library authors were like, I just don't care if the 98 part of the build matrix fails. I just don't care. Like no one's using that. And none of my users complained about it.

I don't care, right? I mean, some libraries like Boost HANA were even very much written just with more than C++ in mind, right? Exactly. That was a 14 minimum library. It wouldn't even work in 11, right? Okay.

So if you've got that support for 98 in there, then someone somewhere in the test matrix has to be running 98 compiler, 98 mode builds with various compilers of your code. And so that's what we dropped support for. We basically said the test matrix will no longer run those 98 builds and report them. Oh, okay.

So the library might still compile. Exactly. Like if the library author cares about C++ 98, it's on them to make it work and tell their users that they might or might not rely on that. But it's not on Boost as a whole and your CI infrastructure anymore. Exactly. So the project as a whole said that we're not going to put any more infrastructure resources towards this support. But an individual library author, they can have their own GitHub action that tests all the 98 modes of all the compilers they use if they want to that's totally fine that is a really really good

clarification thank you so much for explaining this yeah that makes sense and so in particular like one of the previously most popular libraries for metaprogramming was boost mpl right that's all 98 code and none of that's changing and in fact there's a bunch of boost libraries that over time they've been getting off of mpl you know slowly but there, there's a bunch of boost libraries that over time they've been getting off of MPL slowly, but there's a couple of them that I think still use MPL internally for this or that. And so those would stop working if we said like, you know, MPL is no longer supported and we're going to just remove it or something because we don't support an IDE. So it was nothing that drastic. It was just an internal decision that we're not going to focus on that for our infrastructure purposes. Is MPL still useful for anything compared to modern approaches?

I don't think it is. I mean, so there's MP11, which is Peter Demos library, which everybody loves. But I mean, honestly, I don't even use that because like,

I feel like everything that I would do with an MPL or an MP11 or even HANA, like all these different solutions for for people to do metaprogram there's a bunch of other things outside of boost of course but i find that like writing my own sort of bespoke thing is faster for me uh then because like metaprogram is so much easier now like as a 14 i have automatic return type deduction i have to have this big metaprogram to figure out what the return type is of my function um i just say auto etc etc there's a bunch of things like that right i pack expansions to do a bunch of

other things so i find that typically like such libraries are not useful for me and i don't think that um doing type-based metaprogramming that i need a library for it so but that's not to take anything away from mp11 people really love it they get a lot of good use out of it. But that is, I think, the one that people use now if they want to do within Boost, if they want to do type-based metaprogramming, that's the thing they go to. So there's actually one more thing that kind of happened in the Boost community

that might or might not affect real users. I don't actually know. You mentioned this as a news item i think a couple months ago it was april yeah okay so so um there was some controversy or there is some controversy around a group of people who actually set up a parallel boost website like boost io i think that the main website is boost org right and so they set up a parallel boost website boost io they set up a parallel Boost website, Boost.io.

They set up a parallel Twitter account for Boost, a parallel LinkedIn account. And there was this, yeah, it was in April. Yeah, there was the David Sankel's blog post, or I think some post somewhere, where he characterized those activities as like a hostile takeover attempt. Like the people who are like trying to take over Boost and things like that. We have since heard other people from the Boost community

who actually vehemently disagreed with that description. So I don't know what's actually going on. Since you're quite active on the Boost community, do you have any idea what's going on uh since you're quite active in on the boost community do you have any idea what's going on there yeah so i mean in broad strokes uh david's ankle and vinnie falco were arguing with each other like vociferously on the boost mailing list right and this is something that happens every once in a while you get sweaty nerd rage that comes to the surface and uh you get a bunch of people duking it out and i basically i just don't engage with any of this stuff. Right. So like this is not

super relevant to what I get out of Boost or what I think Boost is useful for, which is again, a very high quality peer reviewed set of libraries. Right. And so if people are going to internet on the internet, I'm just going to just not engage with that. So the facts of the case are not that important. The important part is that people got angry with each other and they did it in a very internet way where it was very bombastic. And I don't think it's as big a deal as people made it out to be.

So I think that ultimately, the Boost library is still available for download and that's all anyone really cares about at the end of the day unless they're super into drama. All right, so nothing to see here. Let's move on. Whatever people have said about this is their opinion.

They disagree on that, and that's fine, basically. Yeah. Yeah. Thanks. That's good to hear a take like that from somebody who's actually active on the Boost community, because if you look at it from the outside, you just have no idea what's going on, how serious this is, who's right.

Anyway, thanks for clearing this up. I have one more question about Boost. Is there anything else apart from the B-Man project and the other stuff that we already discussed that's really new and exciting? Maybe any new libraries coming up in the new release or anything else you're aware of that is coming up yeah so um in terms of boost stuff i mean um you tend not to know about anything until like suddenly there's a boost review for it so i don't know of anything that's on the horizon i'm sure there's some people that got some stuff cooking but i don't know what it is um my you know my library hopefully is going

to be and not this upcoming boost release, but the next one. The parsing library. Yeah. Yeah. But other than that, yeah, I don't really know. Like I said, I kind of take Boost as it comes. Because suddenly you'll have a review for this library you didn't know existed, and then it'll be exciting or something you're not interested in.

It just depends. So I don't know really what's going on because it's just the nature of boost i should really check out your parsing library because like i remember i haven't used the kind of parsing libraries very recently but actually i have a little bit of an anecdote i remember my very first job as a cios developer that was back in 2012 at some point they realized it was kind of music software at some point they realized the build was slow they introduced incredibills which does these like distributed like it builds different translation units distributed on different machines to like speed it up and it didn't really work because you know all of the translation units were compiling like in parallel

except there was this one translation unit that was like taking just as much time as as all the other translation units combined which made the whole polarization process completely pointless and that was the one that like had boost spirit in it yeah so uh i i hope that your your library your library does a better job at compile times yeah so uh boost spirit one i had a translation unit that would take 10 minutes to compile. And the object code, when you had debug symbols in it, it was like 120 megabytes or something like this. I mean, it was like a file of a couple thousand lines. It was kind of crazy.

So, yeah, one of the goals that I had going into this was, oh, I can beat those compile times. We have modern compilers with modern language tricks and stuff I can do better. And sure enough, in the first versions of it, it was like lightning fast compared to what Boost Spirit did before. But then I started adding stuff like, oh, you know, I can probably tell that there's an isomorphism between your tuple and this aggregate or your aggregate and this tuple. And I could just, if you want to fill in the value of a tuple and this aggregate, or your aggregate and this tuple.

And I could just, if you want to fill in the value of a tuple using an aggregate, a thing that parses an aggregate or vice versa, I'll just make that work magically, right? And it does that and it's nice and it's fun to use and it really affects the compile time quite dramatically. So over time, I have basically like done all the magic stuff bit by bit to where you have long

compile times again so it's not great it is you know slightly better slightly worse in spirit too it's not as good as it could be but you know if we get uh the thing i hope it happens in 26 which is like good medical programming support like that will improve again. So I think that that would be a definite goal of the library that I basically failed to hold myself to. So I could get there by

ablating features that I don't want to lose. So yeah, it's going to be slow to compile. So it's still boost in spirit? Yeah. You mentioned metaprogramming just then, possibly coming in C++ compile so it's still boost spirit in spirit yeah yeah so you mentioned meta programming just then uh possibly coming in c++ 26 we're definitely talking about it do you have a particular interest there then yeah absolutely so i'm not involved in those papers but i'm like

watching uh just waiting with bated breath for this to happen so you know a bunch of us didn't really even realize that this was um a realistic goal for 26 until about, I don't know, six months or a year ago. I forget exactly how long ago it was, but we had this session about reflection and metaprogramming in which a bunch of people who had been involved in various papers in the past brought forth three or four papers, one of which was like, here's the language feature. By the way, we have an implementation and here's all these other papers that are people using the actual implementation

we already have, which is a modified version of EDG and someone else modified Clang independently, that use the metaprogramming facilities that we have with this new feature to do these kind of libraries that you would want to do that are metaprogramming heavy.

And here's the results and here's what the code looks like. And it's all spectacular, and everyone's on board, and everyone's super excited. And so it looks all of a sudden like we might get this, because the big problem, there's two big problems with any language feature, right? The first one is getting the right design, and the second one is getting an implementation of it

that people can actually play with and road test it and make sure that the design is implementable. It's still efficient in the compiler. It's easy to implement, all these kinds of concerns. Because it's something that's like tortuously difficult to implement, usually it goes away, right? Like the template export thing that was around for a long time.

Only EDG implemented it and everyone else was like, yeah, no thanks. And we got rid of it. Okay. So now those are the stakes. It was around for a long time. Only EDG implemented it, and everyone else was like, yeah, no thanks, and we got rid of it. Okay. So now those are the stakes. And then the reflection part had been cooking for a long time, right? People had been talking about this for like the better part of a decade, looking at different approaches to it. And so when they came with like, well, this is the approach that we took, we knew that the people behind those papers had had that approach before. And so it was not very surprising. But then really recently, they've been talking about how to do the metaprogramming side of

things really well. So reflection is like taking your code and looking at and introspecting and then figuring out, oh, from this struct, can I see the members and can I see the public members and the private members and all those kinds of operations you would want to do with any kind of compile time reflection. And then the metaprogramming side is saying well i actually want to take the result of inspecting a thing and generate some new code based on that thing right so the the example that i would love to have work is could i have a struct that has a bunch of operations on it class struct whichever whichever right there's a

bunch of operations on it and could i feed that to a meta program that says oh i see all these operations let me make the type erased version of this thing so you give me a class with like operations x y and z and i make you a type erased holderased holder with operations X, Y, and Z in the public interface, and then a holder-based class that has virtual X, Y, and Z, and then maybe a virtual clone. And then it has a template that derives from that holder base that is the actual most derived type of your holder. They have a pointer, and you have like a pimple implementation of copy and write. Not copy and write, width of type ratio. And I was thinking of like, you know, you can make the code,

generate the code for doing copy on write or small buffer optimization or whatever other things, make your own V table, however you want to do it. So I think you can kind of do that with this paper, right? I mean, it's like a,

the thing that's been proposed for C++26 is kind of the first step, but it does have things like define class, and then you can say, make me a class that has these members. You can use any output from any of these reflection facilities to build up those members of that class.

Yeah, that's exactly the point. I think you can actually already, with this proposal, you can do what you just described. Well, I don't know what you mean by this proposal. I forget the paper number, but the one that i think that's like the p2996 like the number whatever like the thing that they're proposing for css26 yeah yeah yeah so so that's the point is that i think that we can get all the way to that kind of very rich metaprogramming support like with the stuff that's proposed. And they've been implementing this stuff along the way,

from what I understand. So again, I'm not involved in these papers, but from what I understand, like there is a very reasonable chance that we could get this in 26. There's always the chance that it could slip. That's always a danger. Even the last, you know, 11th hour,

it's kind of thing you could have a slippage. But like, i'm very excited about that that's the most exciting thing i i think is in c++ including like you know i have four papers outstanding i'm not nearly as excited about any of those i am about this language feature um and so you know i think this is going to be for people like me who do lots of value-based generic programming this is going to be a tectonic shift in C++ that is akin to C++14's generalized return type deduction, C++17's if-concepts-per and C++20's concepts, except I think it's going to be more important than all of the above.

Like for me and my day-to-day work doing generic programming, it's going to be more valuable than all those language features combined. I'm just super excited about it. I think you might be right. Yeah, so that's the thing that really gets me jazzed, and I'm really excited to see what happens at the next meeting. We've got a meeting later this month where we're going to talk about the progress of this stuff. All right.

One thing that did amuse me in that story was you used the example of export template, and you even said, only ever implemented by edg yeah and then later you said and this reflection proposal came along and it already has implementation by hang on checks notes edg but you also said clang as well so so hopefully it's going to go better this time. Well, I don't think export template actually was an idea from EDG. They just were the only ones who managed to implement it. The only ones who implemented it. And I think they wrote a paper about the implementation experience, basically because people were like, maybe we should just get rid of this thing.

So what they found was that when they actually implemented the language feature, it did not do the thing that it was designed to do. Right. Right? Like, the whole point of it was to make sure that, like, what was the point of it? I'm forgetting now. Anyway, so it's not important. The point is that it was supposed to do whatever, and it didn't do that whatever. It did some stuff that was subtly different and made it not very useful.

And what they said about it was, I think they said something like, it took us three times longer than any equivalent-sized language feature we've ever implemented. It was so difficult to get it right. And so once people found out it was very, very hard to implement and it didn't quite do what it said on the 10 then it was kind of gone but but that first part is actually pretty important this is something that people outside the committee might not realize but a lot of times there would be a fairly reasonable thing with fairly good support proposes a language change and someone will say like yeah in our implementation this is extremely difficult to implement.

And I'm not sure if we would be able to do it within like 10 years. Like it would be such a rewrite of this one section of our compiler that is really central to how everything operates that we're just like, it's going to be permanently backburnered for the foreseeable future. And so people would be like,

okay, well then we won't do that. So implementability is a real thing that people care about. Yeah. Yeah. I think what export template was meant to have done is you can define the body of a template in a separate compilation. It's the same way that we do with non templates. So we don't have to include the whole template body every time you use it.

That was what it was meant to do. I think in practice it didn't quite work that way. Yeah, you declare the template in a header and then you define it somewhere else. But we kind of have that now with modules, don't we? Except that we don't actually compile the template because you can't compile an uninstantiated template, but we kind of turn it into something

that the compiler can gobble up much faster than source code. Yeah, which is a big step in the right direction and probably the right trade-off. But yeah, that is interesting. Okay, so traditionally, so we are coming up on time, I think. So we kind of have to start wrapping up. But our traditional last question

is kind of something we, I think we just discussed already. So I'm not sure what to do now. So our traditional last question is, is there anything else in the world of CSL that you find particularly interesting and exciting? And you basically said the same thing already that I think almost every other guest said over the last year,

except I think Niels Lohmann said something different, which I thought was interesting. But I think almost every other guest you had on recently said, yes, reflection and metaprogramming is the most exciting thing going on right now. Yeah, absolutely. So, yeah. I think that itself is interesting and exciting. Yeah, I guess it is. So, I think that itself is, is interesting and exciting. Yeah, I guess it is.

So, um, I don't know. Is there anything else you want to, uh, kind of mention or shout out before we let you go, Zach? Um, no, I can't, I can't really think of anything. I mean, I think we hit on like the, the major points of things that are like, you know, getting me really fired up about C++ these days. So yeah, I can't think of anything else. All right.

Well, that's really cool um do you want to just quickly mention like where people can reach you if they want to like talk about boost or any of the things that we have discussed or yeah uh they can't really uh i don't i mean you can email me if you if you really feel uh compelled to do so um my email address is all over uh the committee papers and stuff associated with my name so it's easy enough to find but uh yeah i really don't do a social media or anything like that i feel like it's kind of a giant time suck for me um so i just don't do it um so yeah i don't i don't have twitter or anything like that yeah well that's fair enough i think i'm

kind of reaching that point myself i'm not really using social media either i still have a twitter account i think that's the only one where I still actually have an account, but I have actually looked at it in like a month or so. Kind of getting to that point as well. I'm not sure if I want to stick, like if I want to stick around for all that. But so yeah, I understand where you're coming from. Yeah, I often feel like I'm missing out on stuff

because people will tell me, you know, I'll catch up with people at the committee meetings or at a conference or something. And people are like, oh, have you seen such and such twitter storm but i'm like i have no idea what you're talking about yeah so i miss out on things i'm sure but at the same time i'm like i have like a life that exists outside of twitter that is uh much more enjoyable i think that if no i i did did notice that like at least for me like my mental health is like

inversely proportional to like the time i spend on social media so all right so with that said uh thank you thank you again so much zach for uh taking the time to be our guest today uh we had a lot of fun having you on thank you so much and yeah we'll see you um and everybody else at the next episode. Yeah, thanks for having me, guys. 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 guest or topic, we'd love to hear about that too.

You can email all your thoughts to feedback at cppcast.com. We'd also appreciate it if you can follow CppCast on Twitter or Mastodon. You can also follow me and Phil individually on Twitter or Mastodon. All those links, as well as the show notes, can be found on the podcast website at cppcast.com.

The theme music for this episode was provided by podcastthemes.com.