CppCast - New C++ Scope and Debugging Support

Episode Date: March 10, 2022

René Ferdinand Rivera Morell joins Rob and Jason. They first talk about a new cmake initialization project and some projects in the C++ show and tell. Then they talk to René about his open letter to the C++ committee about expanding its scope to include tooling and other related technologies. News Execution and Static Analysis Support for MSVC on Compiler Explorer Cmake-init C++ Show and Tell experiment Links New C++ Scope Attending C++ Standards Committee Meetings During a Pandemic Debugging Support Sponsors Indicate the #cppcast hashtag and request your PVS-Studio one-month trial license here https://pvs-studio.com/try_free C++ tools evolution: static code analyzers: https://pvs-studio.com/0873

Episode 340 of CppCast with guests Rene, Ferdinand, Rivera, Morel recorded March 7th, 2022. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. In this episode, we talk about CMake FetchReady projects. Then we talk to Rene Ferdinand Rivera-Moran. Rene talks to us about expanding the scope of the C++ committee and the debugging proposal. Welcome to episode 340 of CppCast,

the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right, Rob, how are you doing? Doing okay. I posted on Twitter on Friday that I'm in between jobs at the moment. Oh right, Rob, how are you doing? Doing okay. I posted on Twitter on Friday that I'm in between jobs at the moment. Oh, I missed that. Oh yeah, I'm taking this week off. Friday was my last day at the government contractor where I've worked for the past few years.

Looking forward to the new job, but taking this week off, which is really nice. Do people at your new job listen to CBPCast? I know at least some might be aware of it. I'll probably not mention the new job today because I haven't actually started yet. Oh yeah, no, no, I wasn't expecting you to do that. I'm just wondering if it was all of your worldwide fame that got you this new job or not. I think it was more to do with it being, you know, it's all going to be government contracting work, so similar, you know, type of work. So I've kind of worked with some of the people in this other company I'm moving to soon. So. Oh, that's cool. Well, at the top of every

episode, I'd like to read a piece of feedback. We got this tweet from Robert Ramey saying he was disappointed that Boost Safe Numerics didn't get a mention last week when we were talking about secure coding and integers with Robert Secord. He says it depends heavily on secure coding in C++ book. It traps all non-recommended and undefined behaviors listed in the book. And he posted some links with examples. We are mentioning it now, Robert. It's been a couple of years since we had him on talking about the Safe Numerics Library. And sometimes it's hard to remember all the different things we've talked about with being 300 plus episodes in. But he did talk about this back in 2017 that's been five years yeah you know i have my

monthly meetup and we hang out and chat after the the formal meetup virtually it's been virtual almost every time since the last two years and every every now and then, someone else from the meetup will be like, oh, remember when you had so-and-so on the podcast? And I'm like, you know, we've had like 300 different humans on the show at this point. That's hard. I can remember the people better than I can remember all the different topics we've gone over sometimes. Like, yeah, I remember talking to Robert.

I think we've had him on twice, actually. Yeah, I think I'm almost positive that's right. Actually, I'm better at remembering the topics than the people. Alright, well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cfpcast.com.

And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Rene Ferdinand Rivera-Morel. Rene is a lead programmer at Disbelief LLC, doing game development consulting in products like Borderlands, Gears, Oculus, and more. He also spends his free time doing open-source software like the Lyra command line parsing library, the Barbarian Conan repository intex, and Boost PreDef.

He has been contributing to Boost for more than 20 years in various aspects, but specifically as the maintainer of the B2 Boost build system. Additionally, he's a member of the C++ Alliance, aiming to make C++ widely accessible and useful. Rene, welcome to the show. Thank you. Nice to be here. I want to unpack just a couple of things on here. First of all, I don't think we've mentioned the Lyra command line library at all. Does that sound familiar to you, Rob? It does not sound familiar. I definitely remember talking about the Conan repository index a while ago. I don't recall talking about Lyra. The Lyra command line when it's the fork of Clara. Have you remember that one? Ah, yeah, yeah. Okay. Okay. So maybe it has been actually brought up once. Now that you say that, that sounds familiar.

Yeah. Okay. So that's the one that Phil Nash started, basically, to give a command line tool to cache to binaries. Yes. That's right, yeah. And he gave a presentation in CppCon once about it, which I saw, and I went, I'd like to use it. And then I started trying to make changes and ran into the, well, he's no longer supporting it.

So I went, okay, I'll just keep doing it. And then the Barbarian Conan Repository Index, what is that? We have talked about that also. Yeah, that's the recent work basically creating, I don't know, GitLab has an equivalent kind of thing where you basically put things to have their own Conan repository where you publish things through GitHub through their Git. So it basically lets you make any GitHub project, if you structure it correctly, into a Conan package. Oh, cool. Okay. I might have talked a little bit more about that. Yeah, it makes development of packages way easier.

Yeah, I think when we last covered it, it was right at the initial announcement, and there wasn't a whole lot on there yet to look at. Yes, I remember that. Okay. All right, well, Rene, we've got a couple news articles to discuss. Feel free to comment on any of these, and we'll start talking more about some of the work you've done in this recent proposal you put out there. All right, so this first one is a post on the Visual Studio C++ blog.

And this is execution and static analysis support for Visual Studio on Compiler Explorer. So this is really great to see. Visual Studio has been in Compiler Explorer for a while, but I guess did not have the support for actually executing the code and now has the static analysis features as well, which is really nice. I think brings it up to par with what you can do with GCC and Clang. In theory, I haven't fully tested it. Have you, Rene? I have not tested the execution, either one. But I mean, it is something that I've been missing from Compiler Explorer.

So I'm happy that it's there. I'll go try it. I know the Linux execution environment is very tightly sandboxed to make sure you can't escape. So it was, I'm sure, a whole other engineering effort to do it that the best way on Windows from the Visual Studio team. Yeah. I mean, I know for a while they had the wine execution, I believe. Yeah. I slapped that together in like a day.

And I'm like, here, Matt, you can do Visual Studio. And yeah, anyhow, that's still up there, I think, actually. Yeah. All right. Next thing we have is CMake init. This is a project on GitHub calling itself the Missing CMake Project Initializer. It's always great to see these things for putting together a new project and doing it with all the best practices in mind. And this one is definitely meant for making libraries that will be well

packageable. He mentions using the Fetch Content Ready projects. Fetchable is more important than packageable, it seems. This has been bothering me all morning, just for the record. What has been bothering you exactly? Well, so I've been toying with doing some videos. The FTX UI, do you recall that? That's the command line GUI interface that's come up a couple times in news items. I've been fascinated by this thing for two years. It's now got this huge amount of support.

Their main recommended way of using it is with fetch content. And it just works. I don't have to put it in Conan or whatever. It just works. And that's pretty cool. Okay, so are any of my projects Fetch contentable? And I have to do some tweaking to sort out some details because I've got naming collisions. Because with Fetch content, it downloads it and then does an include directory effectively.

So you make the dependency a subproject of your project, and then if it defines things with the same names, then you're going to get some name collisions. Okay, so I'll have to play with that a little bit. And then I see this, coincidentally, like the next day when we're going over the notes, and this just makes things that are fetch contentable. Now it's bothering me because I really feel like I really have to figure out how to make my projects more usable this way,

particularly in relation to the C++ starter project, which has got a lot of overlapping goals with CMake. I don't use CMake, obviously, since I have my own build system to use, but the libraries that I do make, I try to make them fetch content consumable. I mean, it's not very hard. You just have to make sure you namespace everything appropriately. Right. Yeah. The things that never crossed my mind is namespacing my tests, for example, so that they don't conflict. Anyhow, I think it's interesting. I think our listeners, if haven't looked into like fetch contentable libraries it's i mean it looks pretty cool because in a lot of cases anyhow i'll stop there i will go off on a rant on some of the other frustrations that i dealt with this last week and the last thing we have here is a pinned post on Reddit, and this is C++ show and tell. And this is pretty nice.

Listeners might not know this, but it's technically off-topic to just post any bit of any project you made in C++. If it's something that's a library that other C++ developers can make use of, that's fine. But if you're just saying, hey, I made this game in C++ developers can make use of, that's fine. But if you're just saying, hey, I made this game in C++, it's technically an off topic post, but usually they keep it up anyway. But the mods decided to put this together to let people post all their C++ projects that maybe aren't applicable to have their own thread. And it looks like it's taken off pretty well and there's lots of cool projects in here lots of libraries too but yeah some pretty nice things i was watching the video for one of these video

games that someone posted out grand mountain adventure oh yeah go check that out it's like a ski simulation game and the poster says it's written in 99.9% C++. It's available on Google and Apple. What's the other 0.01%? Well, he makes a note here saying that he wishes there were some examples of communicating between Java, C++, on top of JNI. So I'm assuming he has a little bit of Java and maybe Objective-C in there.

Sometimes it's a little depressing to go to your GitHub project and see like 73% C++, 27% CMake. Like, wow, that's a lot of CMake code in my C++ project. I don't think I suffer from that. Mostly because the language for the build system just doesn't register with GitHub at all. Oh, they have a project. You can fork it and you can add jam so that they'll track that too.

Just go ahead and add that in real quick. It would probably still be quite small. My build files are like, you know, 10 lines and they're not that many. Any other projects either you saw you wanted to highlight in here? One person is making a OneNote knockoff that looks pretty impressively good. Yeah, I think they mentioned it's

written in Qt. They'll make it available for all the different platforms that you can support with Qt. I think it's only Android or iOS so far, though? Only Microsoft Store so far. Windows Store, okay. Yeah, for me, I was unaware of this post until you pointed

it out. So I've been reading through it this morning, and of course the immediate thing that jumped out at me was BuildTool in C++. Which one is that? I don't know how to say it. It's STU or STU, I guess. Oh, okay, okay. I missed that one. I have to go read that one

and look at it. Well, it looks like they've been working on it for a few years even now. I've not heard of this one before. Never have enough build tools. All right. So, Rene, we're going to talk about this new proposal you're putting out. I guess to start off, though, can you tell us a little bit about your own involvement in the C++ committee? Yeah actually I've been going to C++ meetings since 2007 which is the Toronto. Been doing boost development for about five years at that point. Was running my own company at the time and decided well you know it's close enough I can drive I can take this is like two days off just to

drive and ignore my clients for two days and go there. And mostly just listen to what they were saying and going, I don't really know what they're talking about. Is it 2007? 2007, yeah. So the committee was quite small that time compared to today. Yeah, I'm trying to remember. Like they all fit in like two conference rooms at that time. But then, you know, I thought until recently, it's been like every, you know, eight to five years or five to eight years that I end up at a

committee meeting. Okay, so it's been in the last couple of years where I've been trying to go. And of course, the teleconference stuff has helped a lot. Yeah. So how's that gone for you? Are you able to attend a lot of the remote virtual meetings? Oh, yeah. Let's see. Just this week, I have four that I'm attending. Oh, wow. Yeah.

It's like a total of six hours or so. I hate meetings. You know, you do a lot of listening. That's mostly it. Do you have a particular focus in which study groups or working groups do you go to? Yeah, SG14 is the one that I spend most effort on, which is a low-latency games-related one. I happen to be a co-chair for the games segment of it. So I get to chair a meeting once in a while.

What kind of things have you been discussing in that committee lately? Well, we spent the meeting talking about the executors, like every other committee, I think. Wow. But, you know, other than that, the current proposal for Stoodhive is one that we've talked about. We've been, you know, listening to it and, you know, basically providing feedback for it and pushing for it for at least two years that I'm aware of in the committee. Yeah, I know one of the things we've talked about recently in news is that Stoodhive had a paper asking for it to be re-included for consideration in the standard. Do you have any idea how that's going?

It sounds like you're in favor of it. Yes, I am in favor of it. The issue for it got closed, basically saying it's past time, can't include it anymore. Although it is getting committee time this month, I think, and I'll have to check the schedule, but either this month or April. So I'm pretty sure it'll be in 26. So C++23's new features have closed, right? Yeah, they have.

So no chance of executors in 23? No. No chance of pattern matching? No. No chance of networking in 23 then? Oh yeah, the networking losses chance in November, I don't remember. Yeah, there's a lot of things that we try to do executors, but just, you know, in my opinion, just wasn't ready. Just too much changes going on and not tested enough as a design. So from your perspective, has the move to virtual meetings for the committee been like a net

positive or? I mean, for me, yes. Others have different opinions, but, you know, I would not have been able to attend as many meetings and pay attention to as much as going on. You know, virtually means I can, you know, like this week means I'll be working a little later than usual most days just to make up the time. But, you know, I don't have to make up all the time because some of the work that I do in the committees is related to work also. Okay. So could you tell us a little bit about this open letter on the scope of the C++ committee

that you've put out recently? Yeah, sure. So as you may or may not know, I do a lot of tools work, you know, spend a lot of time basically thinking about the ecosystem of C++, basically with the goal of, you know, I want people to use C++ as easily as possible. I mean, like one of the things that I always run into is like people going, well, you know, I don't know what libraries you're talking about. How do I get them? So, you know, there's a lot of stuff, especially recently, I've been doing proposals myself, you know, running into roadblocks of that thing that you want, but you can't do it. It's not part of what C++ is. So, you know, my proposal is we need to take into account the fact that

C++ lives outside of just the language. Hopefully, it goes further than just me sending the letters, but we'll see. So you have this website, and we'll definitely put this in the show notes, and you're basically appending on that the scope of the C++ committee is not just related to the programming language C++, but also supporting tools, supporting technologies, and supporting systems. And yeah, I mean, it definitely makes sense to me because we need all those things in order to develop C++ software. And it does seem like something that has maybe held us back for a little while, maybe a long while. I mean, definitely for me, it is hard to use C++ without taking into

account all those things when you're using it. At times it's heartening when you're in the committee and you try to do something and go, well, you know, complaining about this, you can't do it because, you know, compiler renders can't implement it and those things, but you can't say that in the papers because the compiler renders technically are not, like the stuff that they do is not part of the language itself. So it's a frustrating aspect of committee work. It's kind of like how ABI concerns will often get things shot down because it would break ABI, but technically the standards committee doesn't acknowledge ABI, but it would break ABI, so we can't do it. Right, yeah. ABI is one of the biggest problems with that. Are you suggesting that the scope of C++ be expanded to yeah. ABI is one of the biggest problems with that. Are you suggesting that the

scope of C++ be expanded to actually acknowledge ABI also? I mean, I'm not proposing that it expand to any specific things, just that it takes things into consideration. The things, I mean, the way the scope is written right now, it's fairly vague. It just says it's a C++ language, compatibility with C, and that's basically it. So, I mean, it's pretty broad as it is. And the problem is that you can't make it really narrow. Actually, that's one of the complaints that I got from people saying with my proposal that you're making it too broad.

But at the same time, it's like you make it broad enough that it covers the things that you want to eventually discuss, but you don't know the future. So you don't know what all that eventuality is. Even with that, you still have to go through the process of people in the committee all agreeing that whatever you're talking about is something worth talking about, even if it is in the scope. Do you have people agreeing with you so far? Yeah, I mean, it's been mixed. Some people are really against it. Mostly, there's two camps of the people that are against it, which is, you know, it's fine the way it is. You shouldn't be talking about these things. They've managed

so far. And then the other side is that, you know, yes, I mean, we would love to be able to deal with all these things, but they don't think that changing the scope is the way to do it, that there are other ways to do it. Which, yes, I mean, there are other ways to do it, but the question is, are they as efficient as dealing with it directly? So I guess on that note, you mentioned you're in the SG14 study group. SG15, I believe, is the tooling study group, which was created a few years ago when modules was being worked on. I think we talked recently about how it seemed like that study group kind of was very inactive, at least during the beginning of the pandemic, and it's maybe becoming a little more active again now. I mean, do you think that is an effective way to talk about tooling

in the context of the committee work that can be done now, or do you think not enough is being done there? SG15 is actually one of those other ones that I attend all the time. And it's an effective place to talk about tooling. It's not a great place to actually have that much of an effect on C++ in the language and the ecosystem, because all the technical reports that are working for modules, you can't really do anything specific. Basically, the compiler vendors and the tooling vendors can go, well, sure, we'll take your suggestions in heart and try to do something about it.

But that's as far as it goes. So they do talk about real problems that, for example, modules have in this case and how to deal with them. And most recently, they're trying to get some consensus as to dependency information and how to portray that between the various modules and trying to get that agree on one format for doing that. But even that is hard. It's interesting. I feel like when Rust was first gaining steam, a lot of what I heard from people was, oh, it's so much safer than C++ and that's why we need to adopt it. And I feel like people are saying that kind of thing less and less often today. And now the refrain that I've heard consistently is, oh, well, once you've used

Rust tooling, you understand what C++ is missing. Because it's so easy to use their package management. It's so easy to use their compiler. There's like, you know, default behaviors for these things that everyone just agrees to. I don't know, it seems appropriate to the conversation anyhow. Yeah, I mean, I think that that is one aspect that does need to be addressed in C++, but probably not for the same reasons. I think the main reason that it needs to be addressed for C++ is that the standard library itself is getting a little unwieldy. That might be an understatement, but there are a common pattern that shows up in

the committee meetings is that, you know, you ask the question, is this really what you want or need in the standard library? And there's a group of people who say, well, yes, because that is the only way that we can get libraries to use automotive and whatever else they're talking about widely used. And then you have to reply, well, there are other avenues to get those libraries, but then they complain that they're not allowed to use those other packaging or just externally using libraries

because it presents all kinds of other problems for them. But getting it to a stage where that second option is not a big consideration would go a long way to, I think, improving the quality and what gets into the standard library. The sponsor of this episode of CppCast is the PVS Studio development team. PVS Studio is a static code analysis solution that helps enhance code quality, security, and safety. The analyzer detects bugs and potential vulnerabilities in C, C++, C Sharp,

and Java code on Windows, Linux, and macOS. CppCast listeners can use the CppCast hashtag to get the analyzer's one-month trial version. To request the trial, use the link in the podcast description. C++ projects are getting increasingly complex, too complex for people to analyze them thoroughly during code reviews. That's where code analyzers come in. They notice everything the human eye misses, thus making code reviews more productive and enhancing code quality. Want to know more about the problem? Take a look at the recent article from the PVS Studio team, C++ Tools Evolution, Static Code Analyzers. The link is in the podcast description.

We also have notes here about a debugging support proposal that you worked on. Can you tell us about this? Yeah, so that one was actually an inherited proposal. Isabella Muorte proposed this a couple years ago, just the breakpoint functionality. And then when she, you know, basically quit C++ committee work, I basically, I grabbed it and I went, you know, that is something that I use every day. And I've used for, you know, as far as I can remember, in every C++ project that I've been in. So I started working on it and the first one pretty much mirrored what she was doing with it. And then, you know, I added his debugger present aspect, which was hidden inside,

which is something else I also use. And, you know, the first proposals that I did on that one, the first papers were two. So I kept it split and they used about the same language. And then the second one, I rewrote them all and put them all together because that was a request. And unfortunately, on that one, I also had to do the change where all of the wording and all the actual behavior of the functions move to non-normative notes in the paper. And then the actual proposal just says, this is implementation-defined behavior. Just about all of it. There's one function that doesn't, but that's because it just uses the other two functions. That non-normative notes, that's where you actually have, like, it says note in the standard, and then it explains some detail.

Yeah, those are the notes to the implementers basically saying, well, you really should do this, but we can't say that in the standard because we're not allowed. Because the standard effectively doesn't admit that tools or compilers exist. And a bunch of other things, yes. Right. Basically, everything has to be written within the virtual machine way, and that's it.

Right. Well, virtual machines have debuggers, right? Yes, they do. What do these tools actually do? Like, what does it look like from the programmer's perspective? So in this case, there's just two basic ones. There's breakpoint. Is debugger present? Long name.

Should be obviously just queries, you know, if the debugger is attached when you run the program or when it calls it. Is that the kind of thing that gets stripped out in a release? Well, no, not necessarily, huh? Because you can attach a debugger in any binder. In any, yeah, yeah. Normally, like if you're doing a specific build, like, you know, part of your build process, you would like if that's that out if you wanted to.

But I worked in projects where that's even there in releases. Just because, you know, there's times when you have, in my case, games. You release a game and the testers, they get different versions. They get the testing version and they get the release version. And you need to be able to debug both of them. So having some checks so that you can go in the release version and go, okay, I need to get some information, even if it's minimal, of what it's doing. I've never used functionality like this before at all. I didn't even really know this was a thing. I don't know if you've done this, Rob. I think I have used the Visual C++ breakpoint. Yeah, why would I want to know in my C++ code

if the debugger is present? What would I do differently? So in my case, the common use case is to start doing log output for all the things that the program is doing that you don't want to use. Actually, in the case of consoles, where I do a lot of development, you're not allowed to actually output debug log statements on release mode. So being able to check that you have a debugger present and turning that off is a requirement, because otherwise you won't, you know, they'll fail you on certification. The way I've used it is if there's like a particularly bad error, put in like a, if debugger is attached, break here, block so that it doesn't just get logged. You know, force the developer to go look at what's going on before something like a fatal crash.

Yeah, I mean, for me, since we do a lot of rendering, it's games, some of the conditions that happen for the debugger are not things that you can immediately write in a breakpoint condition for Visual Studio, for example. So a lot of them are if these objects exist and this particular section of the game is in and you're in this particular set of the game is in, and you're in this particular, you know, set of flags that I've, you know, counted down or stuff, you know, 10 to 100

frame of the particular section, that's when I want to pay attention to it and do a break point that something bad happened. Sometimes it might not even be bad, it just be, you know, I want to observe the behavior at that point. Do you ever have the scenario where putting in that test for if the debugger's present changes the behavior of the executable enough that you no longer have the bug that you're trying to catch? That's rare. Maybe I've had it once or twice in my career. There's enough stuff going on in the program that that's usually not an issue. Right. Change the timing, you just broke the race condition. I don't know. I just thought, yeah, that's interesting. Yeah. I mean, for us, we have to make like games, you know, real time and you have to do them

low latency stuff. The timing of things you program the game so that the timing doesn't actually matter because you have to deal with the fact that, you know, even though the screen is displaying at 60 hertz, your game screen is displaying at 60 hertz, your game is not running at 60 hertz, sometimes it'll run at 30, you know, anywhere from, you know, 20 to 100, for example. So you have to deal with a whole variety of timing issues and deal with it nicely. You know, it usually doesn't matter in that sense. So you said, though, that these, like, if debugger present, that can actually end up in the shipping

binary because that would still pass the no logging test that the console manufacturer requires. I mean, is there still some way that, you know, someone who likes to, you know, hack games and, you know, do speed runs and stuff can like still trigger that behavior to get that logging output? It seems like it must still be possible somehow. For consoles, no, because you can't attach a debugger on a console when you're a user. For PC games, yes.

Okay. I appreciate that you can't attach a debugger, but I didn't know if you could still somehow pull the binary on a hacked console into thinking that there is a debugger attached. Because honestly, I have no idea how this behavior works. How does it even detect that the debugger is attached? So on consoles, there is a specific call that you make that the OS supports.

Okay. And then I'm pretty sure, depending on how you run, I'm pretty sure on the actual consoles, the non-development consoles, because we have special versions of the consoles that developers use that have a special operating version of the operating system that has dual modes. So on a console, you can run it on development mode or you can run it on retail mode. And on retail mode, those functions that you call for the OS just don't always return false

or don't let you get any information. So it would never show up anyway. Right, so you'd have to preload a library or something. Yeah, or hack the OS, which of course is on, you know, ROM and it's heavily protected and checksum and all kinds of stuff. Right, right. Interesting. Do you have by any chance CI scripts or anything

that go and check to say like, oops, I accidentally left a bunch of breakpoints in here, I should probably not leave those? That is a good question. I don't know, because I'm not in charge of the CI that my clients do, they're in charge of it. So I know they do a whole bunch of checks for security and validation for the packages to make sure that they can pass and get uploaded to the first party. So that may be one of them. I don't know. So the whole point of this proposal is to

standardize something that everyone's already doing and exists on all the tools. Yes. Yeah, I mean, I think I listed Catch2 has something in there for that. Right. Oh. So you mentioned how you kind of inherited this paper from Izzy when she stopped doing committee work. And I saw that her first paper was submitted in 2018. What sort of response have these breakpoint and is debugger attached or present features gotten from the committee?

While she was doing it, I mean, everyone was in favor of it. They liked the feature. And the latest run was only just submitted to SG15. So it went a couple meetings on that just to get it to the shape that it's in. So I'll be trying the library group again. But, you know, it got pretty good support the last time, so it should be pretty good to get admitted, I think. I know, like, pushback from the committee because of the last topic we had about how, you know, tooling doesn't exist in the committee. I don't know yet. I think

they understood when it was first proposed by Izzy that, you know, the wording would change. Wording always changes all the way up to the last minute. So I don't know how they will deal with it. I will find out. I suspect it will be fine just because people recognize it does exist, but aren't explicit about the fact that it exists. They're okay. But it's a limited field where you can do that. And I guess you didn't get any pushback from any of the vendors saying, well, it's not possible for us to implement this feature since they all already have it. Yeah, normally like SG15, we have Apple, GCC, Microsoft folks in there and they all went, yeah, we have it already. It's in there. Sounds fine. I'm myself kind of wondering at this moment

how standard file system got accepted into the committee since there's no file systems in the standard. I've wondered that myself. I wasn't around for those meetings, so I don't know. A piece of this conversation just came up on Twitter discussing angle bracket versus quote includes. And every team has their own standard for how they use these things. The actual C++ standard says the wording is almost identical for both of them. That says that the compiler or whatever will find in an implementation way search paths to find this header file. Thanks. Yes. That's very helpful. That wording has been used to

excuse things in the committee. There were compilers once that just stored all that stuff in a database and they just created a database to get those files to you, that content to you. Right. But yes, quotes versus angle brackets is a hot topic. So we already mentioned how C++23 is feature complete at this point. Are you hoping this will get into C++ 26?

Oh, yeah, I'm hoping it'll get. I'm pretty sure it will. I mean, assuming, again, that people like it and then they vote for it. But I started early enough. You know, intentionally, you know, when you're, before the, you know, the sender actually gets voted through for balloting, that you can get, you know, some number of things early on

because, you know, library working group is kind of idle. You know, they're just switching to the mode of accepting new things for the next release and they just start just doing feedback, basically questions from the library working group, which is the one that actually sends it off to balancing. So it's a good time to get things in early so that they're out of the way.

Did I hear right that this paper kind of inspired the one that we started with, your desire to expand the scope of ZS Plus? Yeah, it was basically the switch from a lot of comments like, well, you have to change the wording because you're talking about debuggers when debuggers are not even defined. And then if you're going to do that, you have to define what debuggers are, but tools don't exist. And C++ standard has an upfront definitions of things. And that's the kind of section where you define things like tools but you can't because tools are not part of the language so it's kind of a chicken and egg thing.

That must be so frustrating. Yeah, this was the last straw because I also worked on trying to get command line arguments standardized through a backdoor, through libraries and that didn't really work either. So yeah, I keep trying. I don't give up. I guess on that note, what would be the next steps on this addition to increase the scope? Right now you have this open letter, and I do see there's some people who put their name on it in addition to use. Are you hoping that listeners, other committee members, etc.,

more people add their name on this? I sent the letter in on Friday to WG21, specifically the international representative and the convener of WG21. It took a little bit of actually quite a fair number of emails to figure out who I needed to send comments to for both Insights and WG21, because it seems that no one has sent comments in before. When these questions come up for Trignoscope, usually they just keep the same scope over and over every year and no one comments on them.

So they're in. I don't know when I'll hear back what happens. I'll probably poke them a little later today or sorry, a little later this week to figure out what's going on and what can I do next. But, you know, that there is some support from committee members that I can't mention because they didn't sign the letter because they don't want their company, you know, their personal opinion to be viewed as their company's opinion. So I guess, do you have any sense of, you know, what the next steps for this might be? You know, you sent out the letter, but it sounds like it's not the normal case of, oh, I'm writing a proposal and then it'll get uploaded or downvoted. That's not what needs to happen in order to change the scope. Yeah, I mean, at some point it does does have to get voted on, as far as I know. But I don't know what the exact procedure is. But it's not the normal procedure. I mean, as far as I know, it's only like it doesn't go through any of, you know, there's no working groups that really deal with

things like this. The only working group that might, which is a fairly recent one, which is the futures group, which is basically just they just deal with, you know, what they want the goals of C++ and, you know, what should happen on the next standard and things like that. So they may discuss it. I don't know. Those are private meetings that I'm not part of. But at some point, yeah, it would have to be voted on by all the different WG21 members. So all the countries would have to vote on it. I'm kind of curious what end result you're hoping for. If everyone likes your paper to increase the scope of C++

in an alternate past or whatever, it had already become if the scope of C++ had been expanded. Now, what would you have liked your experience with the debugger proposal to now look like? Do you know what I'm trying to say? Yes. First off, I would have loved to be able to refer just to the debugger as a thing and basically say, this is what you should do. Actually, yeah, the wording in WG21 for ISO is, you should. They have special words for,

you know, magic words that they use for, you know, implementers should do things. Right. So that would be the immediate thing. There are other things that you could probably do with debuggers that would be nice. And of course, there's, you know, linkers and, you know, some of the basic things that I want is, you know, standard formats for what, how to identify modules, how to identify module dependencies, which is the biggest, the big topic right now in SG15. How do I identify, like, compile database files so that we can use the same compile database in one compiler and another one, but that also assumes that you have standard options that they both can understand.

So those are the kind of things that I want. Okay. So, yeah. Admitting that compilers and file systems exist and debuggers exist. And linkers. And linkers. Makes it a little easier for getting them to all behave together nicely. Sounds like a bold move.

Yeah. I definitely hope it goes well. I know you said you have had some people say that maybe the increased scope is too broad. I hope it can be changed, though, because there's just these kind of silly games you're telling us about. Like, it just slows things down, I would imagine, and, you know, kills plenty of proposals, makes things unable to do.

Yeah, I mean, at a minimum, I hope that it will start people in the committee actually start discussing how to change the scope and hopefully agree that it has to change, even if, you know, the actual wording doesn't matter. Because, yeah, we're reaching to a point where it's become really, really hard to actually make the kind of properties that many people want. Well, I am kind of curious, we mentioned it at the top, how the Barbarian project is going. It's going slowly, as many things do at the start. Mostly, it's hard to devote time to it since I do at the start. Mostly, you know, it's hard to devote, you know, time to it since I do it off time. I remember last time I checked, I think there were about a dozen libraries up there,

packages that people are using, that I can see. The index is still working, but there's no front page for it yet, which is actually the time that I've been spending the last couple months on and off just working on, you know, REST API so that you can actually query the index and eventually create a set of web pages where you can actually see what's in there. Okay. So it's just a new remote to add to your Conan list of repositories. Yeah. You put the new remote in and you don't even have to wait for the indexing. Like the only thing the indexing gives you is that you can search. But basically you can just publish it with the tool that I have, and then you can immediately

start using it in whatever projects you want and telling people to use it directly. The checking that it does is very minimal, basically. It ends up just being the equivalent of just doing redirects to raw GitHub to get things out of your GitHub repository. Okay. So the projects, they do have to be defined to be kind of friendly for this. Yeah. And you have to use a tool. So the way it works is that actually creates a detached branch in your project that holds

the artifacts for Conan. Oh, interesting. So it's all in your repo, you know, basically creates a database right there. And then, you know, it just queries that branch all the time for whatever project stuff. This is similar to GitHub pages. Yes, similar. Well, Rene, it was great having you on the show today. Thank you so much for telling us about this proposal.

I guess it's maybe too late for more listeners to sign on the letter, or would you welcome that? Do you think it might help? I welcome them signing at least a WG21 letter, not the INSYS one, because INSYS one is just the comment period for that and then that I could send it in. But, you know, I always welcome people signing it. Shortly after this, I'll go post a comment saying, you know, I mailed it, but, you know, you're welcome to continue signing it because, yeah, I mean, I just want to hear what people think about it. Very cool. It was great having you on the show today. Thanks for coming on. Thank you. It was great being here.

Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon.

If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.