CppCast - CppCon 2024 Live Special

Episode Date: September 20, 2024

Phil and Timur are joined by a live audience at CppCon as we chat about Safety in C++, AI and the running of CppCast itself. News Clang 19.1 released Sean Baxter's "Safe C++" P3390R0: "Safe C++" - Sean's work written up as a proposal partnership announcement from C++ Alliance Summary article on The Register Links Core C++ (Israel) - Call for Speakers closes 22nd Sept! "Robots Are After Your Job: Exploring Generative AI for C++" - Andrei Alexandrescu's CppCon 2023 talk

Episode 390 of CppCast, CppCon Special, recorded 17th of September 2024. In this episode, we talk about Clang 19 and about Safe C++. Then we are joined by the audience here at CppCon who can ask us anything. Welcome to episode 390 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, Timo. How are you doing? I'm good. It's a busy week. We're at CppCon. You're actually both I'm all right, Timo. How are you doing? I'm good.

It's a busy week. We're at CPP Con. We're actually both sitting here right next to each other. We are. It's been a busy week. We had the safety panel yesterday. We're doing this today. Yep. You have your talk tomorrow. I have my talk tomorrow. We have lightning talks. And I've got a talk on Thursday. There's a lot going on So, yeah, trying to get enough sleep to not drop dead. But going well so far. How about you, Phil? Ask me next week. I'll know better.

But so far, I'm struggling. All right. So at the top of every episode, we'd like to read a piece of feedback. Actually, during the last two weeks, we didn't actually receive proper feedback emails. What we did receive was a couple of very concrete suggestions for topics. So thank you. We'll consider them. But you can also actually today give us feedback right here

in the room later during this episode. So I'll just defer to that. We'd like to hear your thoughts about the show. You can always reach out to us on xmaster on LinkedIn or email us at feedback at cppcast.com. Joining us today is our live audience here at CBPCon. Thank you all for coming.

So before we open the floor for questions from the audience, we do have a couple of news articles to talk about. But if any of you really wants to comment on those, then please come up to the mic here and you can also comment on our news items if you wish to do so. Our first news item for today is that Clang 19 was released. The announcement was literally today. The release notes say that it represents six months of work from the LLVM community. During this period, there were 1,502 unique authors who contributed 18,000 commits,

corresponding to about 3 million lines of code and 1.6 million lines of code removed. Should be fine. What can possibly go wrong? So there's a lot of new stuff. Obviously, we can't cover all of this. There's been some improvements to C++ 20 modules. Apparently, module import now works properly. It's good news. C++ 17 support is now finally complete as of right now. I was surprised to read that in 2024. But apparently there was this teeny tiny feature

that was missing from C++ 17, which was some defect report from 2016 that has something to do with a change in template-template argument matching rules, something like that. So that was the last little bit that was missing from C++17. So now Clang fully implements C++17.

So that's great news. And more exciting news, they also implemented Nico's fix for the range-based for loop, where you could get undefined behavior very unexpectedly. They implemented the assume attribute, which I'm obviously very happy about.

They implemented, that was the thing that I found most exciting. They implemented C++26 pack indexing. So they actually already implemented a bunch of features that aren't even in the standard yet, that are still in the draft that we haven't standardized yet. But that was my favorite one. So if you have a pack, like in a variadic template or something, you have dot, dot, dot, which represents a pack.

You can now write dot, dot, dot, square, bracket, two, or whatever index number, and directly index an element of that pack without having to expand it and do the whole template thing. So I thought that's going to be really, really useful for

any code that uses variadic templates, basically. Especially zero and size minus one. Yeah, those are the ones. You don't have to write template specializations for those anymore. That's kind of just indexed them. Brilliant. There's a lot more stuff, both on the library and the language side. We don't really have time to cover all that,

but I encourage you to check it out. And the second big news item for this week is that Sean Baxter's work on SafeC++ and his borrow checker that's been going on for a while, and we had him on the show as well to talk about that, is now a formal C++ standard proposal. So there's now a paper P3390, which is a proposal to add all of the stuff to the C++ standard. It's a very, very, very long paper. There's also a co-author from the C++ Alliance. I forgot the name. There's two authors on it now.

Okay. And it also includes a whole new C++ standard library that has been written with borrow checking in mind. There's like a std2 colon colon vector, which is fully bounce checked, fully integrated with the borrow checker. They kind of need a new standard library for this as well, because none of the existing types really work with the borroworrowed Checker. They work with references and pointers,

which we can't do anymore in this world. So yeah, huge new proposal. Let's see how that's going to go. There's also a website for this project as well. So it's kind of more formally now like this is a project. There's a website. It's called safecpp.org. Currently, it just redirects to the paper, but I suppose there's going to be more content later. And important news, there has been an announcement that's been published a few days ago by Vinny Falco,

who is the president and executive director of the C++ Alliance, that the C++ Alliance has now formed a partnership with Sean Baxter. To develop the proposal further, they would also like to involve the C++ community. They write, so Vinny writes in the announcement, we are seeking feedback from developers, researchers, and other stakeholders on the SafeCSS extensions proposal.

So that's all of you or all of us. We're invited to give them feedback on this paper and on this work, which is now being done in partnership with the C++ Alliance. There's also a good summary article on theregister.com about what happened, what's going on there, which I thought was helpful to just get an overview over those developments. So we'll link all of that stuff in the show notes. I think that's pretty big news. So there's now an organization behind it. There's a website, there's a proper proposal. We discussed this a little bit on the safety panel yesterday, last night. I don't know if one of you was there. It seems like it's not really straightforward that we just add this to C++ and then we solve all of our problems because it's just so different

from how C++ works today. So I wouldn't say it's a sure thing that this is going to go on a standard as is. I think there's going to be lots of interesting discussions around that. But we will watch these developments with great interest. Yeah. You said it's a big proposal. I think that's a bit of an understatement. It's as big as any individual standard, I think, just in one paper.

They're pretty close to it. And lots of features in there that actually we've been trying to get into the standard for years maybe we'll get them one day but it's gonna be tough getting them all in in one go so i imagine it's probably going to be split up at some point but that's my i mean it also contains things like destructive move and like the the relocation stuff but which there's i think two separate papers actually that are being considered right now yeah so i don't know how to unify all of this. I'm sure they'll figure it out.

Yeah. I think the fact that it's all leading to a particular goal that's really important, that's the difference that may mean that we actually get something in this time. So I'm hopeful. Okay. So now you're ready for the main part of the episode. We have 46 minutes left because we only have a limited time slot here at CBPCon. So it looks like we're going to actually have an episode that is going to be under an hour this time, which is what we are supposed to aim for every time.

But we kind of fail at that most of the... Yeah, well, I can slow the recording down a bit. Anyway, so yeah, we got about 45 minutes left for questions. So we're happy to talk about anything the podcast itself how we make it or anything about c++ and what's going on in the world right now what we are involved in or whatever you want to talk about so please come up to the mics and let's chat because we don't really have anything else prepared so it's just going to be a conversation between us and you um so let's see where this goes. This is completely unscripted.

We have no idea where this is going to go or what's going to happen. Just like every other episode. Let's see. First question. Maybe you can introduce yourself if you want. Okay. I'm Klaus Egelberger. And I'm interested in whether we want to keep the schedule of every two-week episode.

Because before, Jason and Rob did this every week, which of course brought more content. So do you want to keep it at two weeks or do you eventually plan to speed this up? I can try taking this one, see what Timo thinks as well. But I think the two-week schedule has worked out well for us. It's something we can actually stick to. I think one of the big things we didn't want

was that we would sort of run out of steam and the show get cancelled again or just fall to an irregular schedule. But the two weeks we can actually stick to. And I think that's the important thing. Most of the time. We had a couple of times where both of us were like on vacation or one of us was on paternity leave or something. And we had a longer gap, maybe like maybe twice or something.

But yeah, most of the time we're actually managing to stick to two weeks. Yeah. And I think at this point, moving to one week, because we have considered it a couple of times, but it's just a little bit too much work for the both of us fitting because we're often traveling and lots of other things on the go. No, I think I'd love to do every week, but just realistically with our schedules and everything that we have going on, I think it just would be too stressful. And you want to keep it fun.

When we took over from Jason and Rob, it was quite important to them that we have a regular schedule. But like they said, from their perspective, if you have to go to every two weeks, that's fine. But I wish we had the bandwidth to do it every week. But it's just with our current other commitments it's just we can try we could probably do it but we would probably burn out at some point so just probably not going to go there just yet yeah yeah previously when i was doing cpp chat with uh with john kelp we started out doing it weekly and we actually made the tagline strong opinions weekly held it's's actually right there in the name.

And then it sort of dropped to two weeks and then like every month and then it got irregular. And that's what we don't want to have. So we're guarding against that. Yeah, I think it's probably good to stick to the current schedule because it's better to, better than doing it weekly would be doing it strongly the way that you have been. So yeah, that's a good call. Can you introduce yourself? Yeah. My name is Chip Hogue.

I think the Sean Baxter paper is really interesting. I read part of it, but one of the aspects of the paper that I wanted to call out for sort of highlight for the listeners who might not have gotten to read it yet is that he's taking a kind of incremental approach in the same spirit that like Herb Sutter in his keynote last year talked about for the CPP front, CPP2 to where you don't have to go all at once. You can add or convert like small parts, even like less than at the sub-translation unit level to this. That was one of the central goals of the Sean Baxter paper as well. I just thought that was worth calling extra attention to. I guess when I saw Herb's talk last year, I found the

TypeScript for C++ approach, where you take the incremental approach, I found it very encouraging because it seemed like it's an approach that can actually work. Yeah, very good points. Thank you. I think the one difference is with CPP2, it's got the additional benefit that if we decide to stop using CPP2 after a while, you can take the generated code and then go back to just standard C++. Well, I don't think quite have that possibility right now. We circle, but obviously if the paper goes through, then we may get the features in C++ itself. And that's the way forward.

Yeah, that's a really good point. I hadn't thought of that, but thanks for calling that out. We talked about this at the safety panel quite a lot last night. Right. Is that going to be on YouTube? That is going to be on youtube that is going to be on youtube probably a few months from now but i don't know how quickly they release it but that is going to be on youtube yeah um well it's kind of weird because on the one hand i think like it is the most comprehensive approach to addressing memory safety and even threat safety, which most of the other approaches don't solve that we know of, right? On the other hand, it feels like it's kind of just Rust with

a C++ syntax rather than actual C++. And there's like a weird kind of impedance mismatch there because it does solve the problem, but like the price you pay is that you you have to rewrite a lot of stuff in this new world. And it's not really, I guess it's more compatible with C++ than Rust because there's the same object model underneath. But I'm not sure how much that actually gets us because you can't make any existing code safe that way, right? Which is kind of what people are saying that we should be working on. But I don't think any approach will give us that, whereas this will give us the ability to actually move towards safer code and concentrate on the areas that are needed the most. Yeah, so let's see what happens. I mean, I think there are approaches to making existing C++ code more safe.

So we have now unutilized value reads no longer being UB. Oh, yeah. We have, I think this was actually in the LLVM release notes, that trivial infinite loops are no longer UB. And I think one thing we can do regardless of this whole thing with safe C++ is that we can just chip away at those things, right? Absolutely, yeah. And I would also really love for some point to integrate that with contracts.

Obviously, this is kind of something I'm very interested in because erroneous behavior and contracts are kind of the same thing, except it's like contracts apply to core language constructs instead of your own library code. But you can kind of integrate them in a way that's really cool and will turn a lot of UB into just

the compiler can do something else or call your violation handler or something. It's not going to solve the memory safety problem, but it might chip away at all of these other like things that are unsafe in the language today so i i hope and expect that we're going to make more progress with that until 26 and until 29. yeah that's great really both both things as you say they they don't actually cover each other's features so i think i think the message that we need to get across as a committee is i mean i don't want to descend this into like a committee panel thing but um that on the one hand i don't think

there is a magic switch where you can like flip a switch and then suddenly c++ is safe or as safe as whatever other language i don't think that is possible but it doesn't mean we're not doing anything and and we you know we're not running around like headless chickens. We have concrete things you want to get done to improve safety in C++ in very concrete ways. And we're working on it. So I think that's kind of a message that I'd like to maybe, I think hopefully we can get across a bit more.

Yep, sounds good. And I think you provoked Klaus, he's back. Indeed, so Klaus Egelberg again. I think there's one important point that we should not forget. We are pretty much the 1% in a community that really is at the bleeding edge of C++. And actually, I believe that 1% is already exaggerated. It might be 0.1%. So what about the 99.9%

of C++ developers? They will not rewrite any code. They're not even using context per today to check for undefined behavior. No, this is not people that will do any of these. So I believe it's actually

a pretty important point that perhaps in upkeeping standards provide some switch, something that helps these people to come to better code. Else they would have to rewrite everything. So apart from the kind of individual, like un-UB things proposals, you also have the, what's it called, profiles.

Profiles, yeah. Which I think are aiming to do exactly that. So let's see how far we get with that. But I think that's a promising direction. Yeah. Once we get all of these features, then there'll be a profile. Well, if we get profiles, there'll be a profile that says only allow code that has these features in.

And as those features expand, so will that profile, I imagine. Thank you. It was predictable that this was going to be about safety. Well, it's a topic of the moment. I will take another domain that is also predictable. Can you introduce yourself, please? Oh, yeah. I'm here, Kiosh.

I am here. Hi, Timur. Hi, Phil. here um hi tim or i feel um what is your view on ai in in respect to the near future and the long run 10 15 years from now on software programming and on c++ i'm gonna get phil go first on uh well first of all i think c++ is going to around. I don't know what it's going to look like. Probably not that much different. Maybe we'll get these features, certainly some of them, whether we'll get all of Sean's proposed features.

I'm less optimistic, but also hopeful. But I think also it's going to be interesting to see what other languages come up, whether Rust really delivers on its promises. It's not quite fully taken off yet. Maybe nobody's actually going to be using C++ for new projects anymore. That's been talked about several times over the last two or three decades. So far, it's going quite well. So I think we're going to be in a similar situation there. But if you can write a new project in Rust or whatever the next language is going to be in a similar situation there. But if you can write a new project in Rust

or whatever the next language is going to be, maybe that's going to be the way for most people. So in a way, you feel that it will push other languages better? Would it be an advantage for other languages more than for C++? I mean, sticking strictly to what we've just been talking about in terms of safety features, that's really hard to retrofit to a language. And Sean's done a Herculean job being able to make that work.

But it's going to be much easier with a newer language. So Rust has a big advantage there. HiLo could be another approach that's very early stage at the moment. I'm not even talking about the strictly successor languages. I'm thinking just about fresh new languages. They've got a big advantage that they can start with that in mind from day one. And there is none of this having to rewrite older code that's going to really hold back C++,

as well as the backwards compatibility story. So whether that's going to be enough of an advantage, that's what we'll have to see. That's my opinion anyway. Do you think of your take yet, Tim? I don't think I have much to add to that one. Yeah, predictions are hard. Are you using JNI, Copilot, JGPT,

Perplexity in your daily work? I tried it out. I'm hearing that everybody is now using it and you can't do anything anymore without it. chat GPT perplexity in your daily work? I've tried it out. I'm hearing that everybody is now using it and you can't do anything anymore without it. I've tried it out a few times. I think I use it for things like, I don't know, when I write committee papers, for example, I do that in LaTeX.

And I forget a lot of the time how to do stuff in LaTeX. So I was like, hey, chat GPT, can you like make me a table in LaTeX with like two rows and three columns or whatever? So anytime there's like something that's like really like not interesting intellectually, but you kind of have to type it out. And I don't remember or know how to do it

off the top of my head. Like that's when often I ask AI to just do it for me, because that just saves me a lot of time. But that's pretty much the only use case I found for it personally. As soon as it gets more complicated, I feel like if there's interesting code, I feel like I spend more time looking at what the AI did and trying to figure out if it's actually correct than just writing it from scratch. But I know that, for example, JetBra jet brains where i used to work like and i think or many

other companies i think probably everybody everybody these days has like i i integrated in their products and you have all of these features where you can like select the code and say like explain what this code does or whatever and i have to admit i haven't tried out like these really new features yet so yeah i don't know maybe i should i don't know do you have an opinion should i use it should i use the stuff my opinion is that it is a great tool i mean i'm using that and and you have to of course check what you get and that's the same as any piece of code that you get from somewhere but uh it actually works i you mentioned ISO proposals, and I remember that there were two examples when CGPT just went out of two ISO proposals that were not submitted at the end, but created

with CGPT on enum to string. I don't remember the people, I think Vittorio Romero was one of them who said, oh, this is a paper that was 100% generated by AI and it looks quite good. Maybe I should switch my approach and just, you know, when I have some feature that I really want to be in the standard, I'll just let the AI write the whole paper. Don't stop with the tables. I mean, tables is just, you know, the beginning. Just ask the AI to prepare the paper and then review it.

I mean, that should be the approach. I don't know how I feel about that, like ethically. Like that's a deep topic. Oh, that's a question. Well, the next stage will be to actually get something like ChatGPT reviewing the papers on the committee as well. We don't really need humans involved anymore. This is why I asked for the long run, for 10, 15 years from now. I mean, what we can do now, I mean, we all see,

but the question is much more for the long run. And in a way, yeah, it hurts our professional pride, I guess. Yeah, I think, as you say, they're useful tools. Currently, the results are varied, but they are definitely getting better over time. And maybe we'll reach another inflection point and we'll take another big step forward. But I'm not sure they're ever going to get to the point where we're not just using them as tools to help us with the job. And maybe we'll write less low-level code and it'd be like a high-level language in its own right but you've still got to know how to write the prompts and tell it what what you need to do and interpret the actual requirements i mean the other thing is that by its nature it's always like

behind by however like however all the data is that it's been trained on right right so so there's always like this time lag between what the eye knows and what like humans know about any given topic. And then you get the regurgitation problem of it starting to be trained on data that it itself has produced in the past. So I can say we've got a few people now being provoked. Of course, I want to chime in. So let's not forget that it's heuristics only. So last week in Kongsberg at NDC Tech Town, there was actually a good talk about AI-generated code. So Anastasia Kozakova was doing that.

And I think she asked ChatGPD, please write some code to count something. And the result was a for loop doing something. And then, of course, she said, ChatGPD, isn't there an algorithm to do that? Oh, I apologize, blah, blah. Here's the count if call. So the explanation for that

is, I think Anastasia then asked, why did you first show the for loop? Then Chet Chibidi explained that this is because it should be educational, right? So in incremental steps you make the code better. But I actually believe this is just heuristic. More people would write the for

loop instead of using the algorithm. And so to some extent, chatGPD gives you just what most people do because this is what heuristics does. That's a really good point. So in languages, spoken languages, probably the most spoken language is bad English. And probably in C++, it's what you see most via chatGPD is bad C++. It's heuristic. That is true, but I think they're all problems

that can be solved or reduced over time. But we're never going to solve the problem of it's not going to be able to make those decisions for you. It's just going to be able to give you the options that you can choose from. I think maybe the best way to put it. Yeah. My name is Vitaly. the options that you can choose from. I think maybe the best way to put it. Yeah. Yeah.

My name is Vitaly. I can get to like this AI topic a little bit because as it was said, it's like really depends on what you've been working on because last like 10 years, I'm mostly working on, I guess, libraries, frameworks and stuff. And when you ask AI, new generation, previous generation to generate you something like

heavily templated or like more or less complicated not heavily templated just you have to try this i'm not sure like bind back bind front functions or something like that and if you get it compilable you like like enough so from my point of view i see like basically two things where you can use ai nowadays the first one is when you do tests right and you generate some test data a lot of test data or when you need to cover something with rather primitive tests with both like positive negative scenarios or the second one there was a talk i do not remember what was that but it was some mit guy and he basically said that say like if you can properly train it say on the company internal knowledge base then it could explain fix something for you and whatnot but other than that like for

say complicated scenarios i still like don't see it as a good tool perhaps the scale of 10 years or something like that that would be developed but i'm not sure how that can be if we use the same networks or the same approach because it's just definitely probabilistic stuff and rather primitive thing so yeah you mentioned tests in there and i do a lot of uh talking and training with regards to testing and i tend to meet two groups of people when they when they bring up ai there's the the groups of people that want to use ai to generate tests and then there's a group of people that want to generate the implementation from the tests using ai and my concern is when those two people get together. Yeah, I mean, there are another nice example. So in our company for testing, we use K2. And there are still some tests that are written with Qt test framework. And when

I asked just for, say, for out of interest, please, can you take those tests in Qt and then mechanically port it to cache 2. And it was mostly fine, like perhaps 95% correctness, but it wasn't fully correct because it used the previous version of Qt to port it. So that was never compiled before our codebase. When I asked to fix it, it wasn't fixed because the data wasn't presented in the models yet. It was only like an updated Q documentation. So yeah, mostly correct. It reduces amount of work in this case for tests, but still not fully correct yet.

But I think the question is, I mean, as Klaus said, it's just heuristics, right? So if you expect it to actually understand what's going on and produce correct code, then maybe you're misunderstanding what it does i think the question is did what it produced save you time like is it a useful tool like the way hammer is a useful tool or or like did it introduce like subtle errors that took you like longer to fix than if you had written it from scratch i think that's the that's the question yeah that's a very good question i totally agree like that for some cases it would save but like

depends on what you are working on what you're doing safe it's regular feature development job or you're doing application like developer code not foundational like libraries or something that would definitely save you some time yeah i think that's why i'm skeptical and i'm not using it currently except for stuff where it's like tedious to type but like if it's typed i can immediately tell if it's correct or not right so that's what i use it for uh so i i know up front it's it's going to save me time or if it's wrong i'm just going to see it and throw it out anything where it's more difficult to tell whether it's correct, I'm just skeptical. But that's just me. I think, yeah, I don't know. Phil, what's your take on this?

So I think some of that is true right now, but that may improve over time. So it's less of a problem. And particularly if we do get to an inflection point where rather than just being heuristic based, there is a little bit more of what we might call understanding, whether it's actually understanding, doesn't even matter. But if it looks more like understanding, that may actually take us further. But I think one way to think about this, which I found really useful, is to use something from the systems theory domain called Kenefin, which is actually a Welsh word. I think it means home.

But it's just a way of dividing up types of complexity. You've got these four domains, actually five if you include, uncategorized I think they call it. But the first one is a simpler, obvious domain. And if you think of software projects where all of the main things are unknown, you know, done this lots of times before, line of business application, some sort of, you know, CRUD system. And you can get a junior developer, probably knock that out. Ideal application for AI to probably write the whole thing. Maybe not now, but I can see that happening. The next domain,

I always forget which one it is the complex or complicated domain let's call it complex is where it takes a domain expert to really know how to proceed but it is all knowable up front and they can write specifications and then other developers can go off and develop it and that would be a really good application for ai as well again maybe a little bit further down the line it can take on more of that but it should be able to do all of it really but then you get to the let's call it the complicated domain those may be yeah switched around thanks ralph so okay this is the complex domain the previous one was complicated where it's now more sort of an emergent thing you're going to run some experiments to see what works

and then based on that you're going to iterate and say right now we can finally solve this novel problem that nobody's solved before or not in this particular way and that's going to be much harder i think for ai to just come out of the box and solve it but it may be a really useful tool to help you get there great example of of that was a couple of years ago, Andrej Aleksandrescu gave a talk here where he was using ChatGBT to help him to come up with a more optimal solution for binary search. That was, yeah, last year. I think it was the closing plenary, maybe? Could have been, yeah. Maybe it was last year. We'll put a link in the show notes I promise and then the final one

that the chaotic domain is basically where everyone's on fire and you just do whatever it takes to solve the problem you've got no idea what's going to work

you just have to keep going until you fix it but if you frame it in terms of those domains then maybe there'll be less need for human developers in the first

and maybe second domain overall but those other ones are where the value really is so that's sort of There'll be less need for human developers in the first and maybe second domain overall. But those other ones are where the value really is. So that's something I found useful to think about. Yeah, I also have some experiences with, we use GitHub Copilot. And some of the work I do is on a units library. So there's a lot of template metaprogramming in the sort of hidden implementation details. It's actually not too bad at being familiar with a lot of the common template

metaprogramming idioms. And I mean, to get to your point earlier about like, does it save time? I think sometimes the answer is actually yes, it kind of saves me a good amount of typing, and I can just look at it and I can see. But there's this other interesting phenomenon that I wouldn't have thought of ahead of time, but I experienced it. And I wonder if a lot of other people experience it as well, where I'll be typing and I'm going to feel kind of a strange pressure to keep typing because I don't want it to interrupt me by throwing up an autocomplete suggestion. I don't know if other people experience that or it's just me. I think I feel that more strongly. Some people nodding.

Nodding? Okay. Yeah. All I can see is you two, so thanks. But I think I feel that even more strongly when, because I'm doing my talk slides in a text editor as well. So something like for prose, honestly, I should probably just disable it but uh for for that kind of application but that's another interesting phenomenon that i've experienced yeah thank you okay we got 20 minutes left let's talk about stuff hi my name is tal um assume i haven't heard a single episode of your podcast, because I haven't, what episodes would you recommend?

Like, give me a really good one so I can get into it. So this is 390. Yeah, that's why I'm asking. We took over the show a little bit less than two years ago. Before that, it was run for a decade or so by Jason Turner and Rob. Yeah. So what's our favorite episode is that the question or you want me to listen to your podcast i assume you want people to listen

yes what would you recommend that i start with so i i would like to keep on listening okay uh yeah andreas episode is good um sean baxter's episode the one we did recently on that stuff that we talked about earlier in the new section that was i think quite quite good we really grilled him like about like what he's doing and why that's a good idea um that those are like the the recent ones that i think are um one of favourites is the one where we actually took over and we did the record scratch in the middle and rewound and became the host. But I'm not sure that's what I'd recommend

for new people to listen to first. But maybe other people have a favourite episode. Anybody want to volunteer? Actually, before we get there, I did really enjoy when we took over, I started listening back to the old episodes from like 15 years ago or something? When did they start?

It wasn't that long ago. Like 10 years ago for sure, right? It was a long time ago. So like listening to the first few episodes. But like Rob was doing the first like five, six, I think on his own. And then he was like, does anybody want to be a co-host? And then like Jason got on board and started doing it together. And like they had like the first like kind of more exciting guests at some point.

And like you kind of see how the show kind of boots up and like starts to like become like really good. And I really enjoyed like listening to the first 10 episodes. So and also it's it's kind of hilarious because they were talking about like C++11 stuff. And it was like the hot latest like news at the time is like really entertaining to listen to that but yeah maybe go back to the first episode listen to that and then maybe episode 10 20 and so on and just like take a sampling through and just see how things have changed over time that could be quite interesting that's a good idea and i haven't thought of that because i haven't still got through all 390 of them.

Right. But good question. But anybody else want to volunteer a favorite episode now's the time? Maybe the one you're on. Maybe we have a few people here who have been on CPPcast episodes. Yeah, how many people here have been on a CPPcast episode? Three? Three people. yeah how many people here have been on a cpp cast episode three three people there's only a thousand people in the room so it's uh that's quite a quite a good

ratio but we need to get more of you on so talk to us about that yeah yeah it counts it counts but yeah if you if you have a topic that you're like really excited about you want to like talk about for an hour just you know talk to us like you don't want to just invite like the kind of famous people who are doing keynotes you want to talk up to like you know people who are like well we try to have a mix we want to hear new voices people just doing everyday work not necessarily the people that are that are changing the way we think about things. But we don't want to do all that either. We need the exciting, well-known people as well

just to keep people interested in coming back and everything in between as well. And I think the challenge is even though we want to try and have a mix of, I don't know, big names, people who have never been on a show before, people who have been starting out with css more recently or um but like we're still in our bubble when we try to reach out to people right so um it would be actually really cool if people would come to us and say hey i really want to do a cvpcast episode about about this topic and like and we go

oh this is cool we haven't thought that. We would never have bumped into you and reached out to you on our own. But thank you for coming to us. And I think that's going to make our topics more diverse. Yeah, and we do ask if you've got recommendations for people to come on. We do sometimes get those recommendations. We've had one or two on.

That's worked out well as well. So if you want to hear from a particular person or a particular expert on a particular topic do let us know and we'll we'll try to fit that in as well yeah that's very valuable feedback it's like i really want to have an episode on on this yeah can you get like this person on like we had a few a few of those like that like for example oh but one other episode i really like the one with neil sloman about the jason library yeah where nobody of us he was like a guy who was a bit outside of our bubble i had never met him before yeah i don't think he ever went to any of the conferences that i went to he's gonna write in now and say i'll be not all the conferences so so he was completely outside of our bubble and the only thing i knew and i don't know about you

like the only thing i knew was just this library and there was this one guy somewhere who wrote this library but because the library is so so popular i was like i need to find him and i wrote him an email and he didn't reply and i was like how do i find this guy how do i reach out to him and eventually we got him on the show so that was that was an interesting one yeah that worked really well so and it was an amazing episode that's one of my favorites actually so so yeah more people who who we don't know yet right that would be really cool i think that would make the show better hey i'm here again uh i will use some of the time left for uh marketing plug uh sure i'm one of the of the organizers of Core C++ Conference, which is taking place this year on November. And since both of you were attending and speaking in Core C++ in previous years,

maybe it's a good opportunity for you to say a few words about the conference and visiting Tel Aviv. Yeah, I mean, I've been there, I think, twice now. Great conference, great great people great quality of talk i definitely enjoyed it yeah it was great i was at the the first one they say great conference great people uh and obviously a different environment to to what we normally see um fortunately it's a little bit harder there at the moment, but I'm looking forward to being able to go back at some point.

Yeah, I'm probably not going to make it this year for a number of reasons. But yeah, it's a great conference. And when is it? Is it because we have a lot of other stuff going on in November, right? There is Meeting C++. There is the Rotswaf committee meeting. Is it like after all that? It's 26th to 28th of November.

Call for speakers is still open till September 22nd. So anyone who thinks about giving a talk, you can still submit. We are aiming this year for a more local conference, even though we do expect to have a few and we already have submissions from speakers abroad um and and anybody of course is invited to submit and to come all right thank you can i just ask when is the podcast coming out because you said september 22nd there's not a lot of time

on friday so that's when september 20th that's when we're going to publish the episode. Still have time. Great. We always publish on Fridays. Yeah. Maybe a little bit later because I'll be editing on the plane, but it should still be Friday somewhere in the world.

So the call for episode recommendations reminded me of an idea that I had had a long time ago, something I would really like to hear, which is maybe do an episode on demystifying the C++ standards committee and all these different WGSG groups or whatever. And in some ways, I kind of don't know if I'm on the standards committee because I submitted a paper, long story, and I started getting replies. And then I tried writing back and the emails all bounced because I'm not on the list. So I had to go through some procedure, and now I have access to some things.

But I kind of found the whole thing very Byzantine and confusing. And if we did a whole episode on demystifying the C++ Standards Committee, I'm sure a lot of people would really love to hear it. So I have been on the committee since when 2016 or something i mean obviously some people were have been on there much longer but i've been on there for like eight years now and i can tell you that i still haven't figured out how some of the stuff works like like literally right now this week there's like a kind of weird procedural issue that I don't know how to resolve. I don't know what the process for that is on the committee. So you're not the only one.

Yeah, we can do that. I think it's a bit tricky because I don't know how many people are interested in that, right? There's like, I think here, there's a big concentration of people who are really interested in the committee and want to get involved or just want to stay on top of what we're doing and all the papers and like how the process works. But I don't know like how many of the people out there who are listening to podcasts are really interested in that. It might be most of them.

I don't know. It might be not that many. It's difficult. Yeah. I think there have been one or two episodes before that have had people on that have gone into a little bit of depth maybe not quite as much as as you would like um and that may be the line that we need to to keep to oh yeah we tried again and jumped here so like you do collect and feedback and you simply ask people whether it's interesting like because for me it would be interesting. We can do one, certainly.

If we do that, we have to tell people that if they're explicitly not interested, they also need to give that feedback. Otherwise, you get a response bias. There are a few questions where there are very unambiguous answers, but it takes you a while to figure out where these answers are. For example, whether you're on the committee is a question that is very easy to answer. If you're on the ISO Global Directory, listed on the ISO Global Directory page with your name and a national body next to it, then you're on the committee, otherwise you're not.

Things like that. What's the Global Directory? I don't know how many people care about that, but we can explain that. And all of these study groups and subgroups. Yeah, I think that's a little the level that a lot of people might be interested in you know how does that actually go through these different stages of the committee what does it actually mean when it's in wording review and

things like that we we actually had there's one thing that i think would be interesting for a wider audience which is actually a second uh committee thing that i'm kind of trying to figure out how to handle right now um we got on st21 which is a contract study group which i'm chairing together with john spicer we got a paper in the last mailing uh from somebody who we don't know there's a name we have never heard before nobody knows who this person is uh they're not on the global directly they're not member of any national body it was not um and they wrote a they wrote a paper um but they submitted it right but they at least figured out how to do that part they didn't figure out how to do the part where you have to sign up in order to actually be able to present your paper so now i need to somehow explain that

to them but like they figured out how to submit a paper, but a lot of people, they don't know how to do that. They're interested, but they don't know how to submit a paper. And we have extensive documentation on that on iscpp.org. You have an idea for a proposal. This is what you do.

Like it explains all of this, but it's a wall of text. And apparently there's lots of confusing terms in there. Maybe that people don't know. People don't read it. So having an intro on that maybe would be useful. Like, hey, if you think you have an idea for the standard, here's what to do. And here's whom to talk to. And if you're still sure that you want to write a paper, you know,

here are the things you need to do then. And I think that would be maybe also interesting, not just the structure of the committee itself. Because that question I had quite a few times from people. And I was so confused when I joined myself in the beginning. I was so confused. I think it got a little bit easier recently. But there's still just the wiki, there's the website, there's this and this and this.

It's all not really connected. Where's the information that you need? I think we should hopefully improve on that somehow, but like, who's going to do the work? Like we don't have, we have zero budget for this, right? So that's, that's the other problem. I mean, the C++ Foundation has some budget, but I don't know. It's, it's, it's a lot of work. Could be interesting to talk about how that fits in as well.

Not now, but. Yeah. There's a, okay. Message received. There's a interesting to talk about how that fits in as well not now but yeah there's okay message received there's a lot to talk about we will we will consider doing an episode about that thank you very exciting but we have to be a little bit careful because one of the recurring bits of feedback we get is when we go too far into like future papers and things that aren't actually available to most everyday developers so i want to try and make that the main focus but occasionally we can dig into the weeds yeah that's why i said in the beginning i'm not sure how many people would

be interested in that because we got i think quite a few emails this year about how some of the topics like i think uh was it sender receiver was one example where people said i don't understand any of this is like like some committed people are cooking up some complicated stuff up in their tower, but it's not relevant for me as a developer. I don't understand any of this. Can you talk about stuff that I can actually use in my code today? And yeah, that's a balance that we maybe

haven't got quite right yet, but we want to improve on that. Yes. Hello, I'm Bolin from Seattle Securities. Yes. fault internal linkage, which is an issue if we put them in headers. So I brought up this topic within my phone. If you know, Gasper is also from Seattle Security, so we discussed and he demonstrated me how to write a paper stuff, like i never got time to do it and and i think this thing happens like for for people outside of the community like uh we we have ideas but like as you explain we just don't know how to properly like make it into the standard or like, I think there is even not a very open like channel for discussing

stuff like this. It may be like a very good opportunity to share like within your like casting program about how we can like make some progress on ideas we have. And yeah, but another topic I want to bring up is still regarding making the standard better. Like currently we have... Yeah, I mentioned we can make our own app source, we can apply for it.

So I'm interested in making an episode regarding undefined behavior specific to reading uninitialized variables. Like Herb Sutter mentioned yesterday or maybe yesterday, about there will be a change in C++ 26 regarding reading uninitialized variable. But I think the change is still missing something.

Like, for example, we can, like, reading an initialized variable can still be undefined behavior, like if we use this intermediate attribute. But there are cases where reading an initialized variable is not a bug and is intentional. Like, I have implemented that structure that take advantage of this. But currently it's strictly speaking, it's undefined behavior because I have to read uninitialized variable and according to the standard, there is no

safe way to do it. You can't read an uninitialized value. You can leave a variable uninitialized. You can't read an uninitialized value. You can leave a variable uninitialized. You can't read it then. That's undefined behavior. That's not portable. You can't use that in a data structure.

Yeah, but that's the issue. Like for some algorithm, we do not really care about what value we read. Even if we, like suppose we have a variable a, it's for my data structure, it's okay if I, before initializing, I read whatever value for it. It can be different value. Like the first time I read it's one, second time it's two, but after I write it, it will always be the same value as I write. Well, if you don't read it before you write it, you're good.

But my point is, it should be defined, like at least, like we should provide a way such that we can read uninitialized variable. But what are you going to read? Because the standard doesn't say anything about real computers and how memory actually works

or any of the stuff. But for example, we can define it as the following. So we suppose we have a, like a type called maybe initialized with a type parameter T we define this type as follows. Um, when default is constructed constructed the variable is not initialized like when we read from the variable if it's never written then the result is unspecified it can be any value like it can also be different for for different rates but once we write to that variable the rate will always return the same value so we have one minute left so i don't think we're going to get into that topic now but uh we have discussed the leave the value unspecified option

as one of i think six or seven options for how to specify this there was a paper that lists them all lists all the trade-off we have discussed this in quite some depth i think we made the right choice but if you're if you don't think we did then we can talk about this but i think we need to take it offline because we have 40 seconds left but uh yes this has all been considered um so i'm happy to talk about this more later, maybe in the hallway. Yes, a surprisingly complex topic with surprisingly conflicting opinions sometimes, but it's all been considered.

Oh, thanks. All right. So I think we need to wrap up. Yeah. So how do we do that? We don't have a predefined text blog for that situation uh no well let us know where we can find you if people want to want to reach you but um thank you all for coming and for providing all the content today uh unpaid i'm afraid but um but you will get to to hear your

your voices this weekend yeah Yeah, fantastic questions. Thank you all very much for the discussion. We'll publish it on Friday or maybe shortly afterwards. Yeah, we'll see where I get to in the editing on the flight. And if you have any more ideas for episodes or you want to be on the show, we want to hear from you. Feedback at cvcast.com is where you can always email us. Thank you very much and enjoy the rest of the conference.

And you can talk to us about any of the stuff for the remainder of the week. We're both here until Friday, right? Well, I'm here till Friday morning. Okay, I'm here until Saturday morning. So yeah, let's talk more. Thank you so much. Yep. 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. 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.