CppCast - Modern C++ with Qt

Episode Date: January 12, 2024

Ville Voutilainen joins Timur and guest co-host, Guy Davidson. Ville talks about his work at The Qt Company and on the C++ standard committee, and about how modern C++ features such as Modules and Sender/Receiver can integrate with the Qt framework. News Matt Godbolt on Computerphile PVS-Studio C++ quiz Boston C++ meetup C++ Now Links P2300R7 - std::execution (a.k.a. Sender/Receiver)

Episode 374 of CppCast with guest Fiedler Wotulainen, recorded 9th of January 2024. This episode is sponsored by about explaining machine code, a new C++ quiz, and some news from C++ meetups and conferences. Then we are joined by Wilder Wotilainen. Wilder talks to us about Qt and modern C++. Welcome to episode 374 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dummler, joined by my guest co-host for this

episode, Guy Davidson. Guy, how are you doing today? I'm all right, Timo. How are you doing? I am great. I have just been on a two-week break over Christmas and New Year's, took some time off. So I'm nice and fresh and relaxed back at work. It is very cold and dark here in Finland. It was minus 25 last week. So minus 25 centigrade, I should say, for our American friends. So it was quite frosty, but yeah, it's fun. And also I should say why you are here, Guy, today. It's because Phil is actually still on a break.

He's, I think, traveling somewhere on vacation and unfortunately unable to join us today. So as we do in those cases, we invite on a guest co-host. And I couldn't think of anyone better than you guys to join us today. So thank you very much for being my co-host today. I'm absolutely delighted. You're utterly sweet. Thank you.

All right. So, yeah, how are you doing? Well, I'm also doing well. I've also, you know, new into 2024. I have started a new position. It's a bit quiet at the moment. I'll give you a clue. If you saw Kevlin Henney's keynote at Meeting C++ last year, that's a very oblique clue.

But that's all I'm going to say for the time being. I'm still in games, but I've left Creative Assembly now. And I'm pursuing rather interesting new challenges. The weather in Brighton and Hove right now is very, very cold. We had our first snow yesterday. And I think January is going to be quite miserable, but not as dark as Helsinki. All right. So that sounds really interesting. I'm very much looking forward to hearing more about your current endeavors in the future. Well, you shall certainly hear, but not just yet.

All right. So at the top of every episode, we'd like to read a piece of feedback. And sometimes after we released an episode, we don't get any feedback at all. Sometimes we get loads. Not all of it is always positive. And that's good. You know, you want to have negative feedback as well to improve. But this time, actually, we get loads. Not all of it is always positive. And that's good. You know, you want to have negative feedback as well to improve. But this time, actually, we got loads of feedback on the last episode. And it was overwhelmingly positive. So thank you, everyone, for submitting your feedback. It seems that people really liked the holiday episode that Phil and I did just with ourselves

without the guest. It's kind of a bit of an unusual format. So I guess we will maybe do that again sometime. It kind of worked. I'll just pick one of the emails that we received. This one is by Matthew. Matthew writes, I enjoyed hearing this format for the special occasion.

There seemed to be a tiny bit of doubt in your voice about how the show was going. Let me just clear that up. You guys are doing great. And this is still one of the best podcasts around in any category. Well, that's very generous praise. Thank you very much. Thank you very much.

Thank you very much, Matthew. Matthew also writes that the access you give us to top people in the community and interesting topics is fantastic. I'm sure I speak for others in expressing my deep appreciation. By the way, I sell podcaster shoe polish, and I really think this will increase

your download numbers. Podcaster shoe polish? Yeah, yeah, yeah. We had a bit of a rant last time uh at the episode about how we get all of these emails from people who want to sell us podcast guests or software that manages podcast guests or software that does other podcast stuff apparently it's a massive industry and everybody wants us to give them money for i don't know finding guests or something or some other

stuff that we don't really need because we can already do it ourselves. Anyway, thank you, Matthew, for the positive vibes. We do really appreciate it. For everyone else, we'd like to hear your thoughts about the show. And you can always reach out to us on xmaster on LinkedIn or email us at feedback at cppcast.com. Joining us today is Ville Wotelainen. Ville Wotelainen is a principal software engineer working at the QT company and has been programming in C++ as a hobby

since 1994 and professionally since 1998. He has been a member of the ISO C++ Standards Committee since 2009 and has authored and implemented various standard proposals over the years. Ville, welcome to the show. Thank you. Okay, Ville, I'm going to have to stop right here. Is it cute or cutie? Because I've heard both, and I'm sure there is one canonical pronunciation. Can you tell us what it is?

Well, the canonical one is cute, but various people, both external and internal, use both pronunciations, almost interchangeably. So we are not all that pedantic about it, at least our developers aren't. I'm delighted because, as you know, as you probably know, pedantry is one of my strong suits, and I always like to get things correct. So now that I know that neither is correct,

so this has been a great day. Thank you. So I think we actually have all three of us probably have that in common. I think that's true. All right, Wille, we'll get more into your work in just a few minutes. But first, we have a couple of news articles to talk about. So feel free to comment on any of these. Okay, so the first news item for today is that 2023 is over, as you might have noticed. And ISO actually has not yet released the C++23 standard document, although we have finished technical work on the standard almost a year ago. And that means that C++23 will only be officially released in 2024.

So I think that the standard will actually now be officially called ISO IEC 14882 colon 2024, not 2023. So Ville, Guy, I don't know, can you maybe, can either of you explain what this means? Will we still call it C++23? Or will we call it C++24 now? Because like the official name will be like something something 2024 yeah so i think i can shed some light on this matter um this has happened before so when we are done in the committee uh when the final ballot has passed the editor still does some

purely editorial fixes on on the actual standard document. But it gets sent to ISO for their internal processing for the publication, like a month before the year's end. And they do some red tape bureaucratic things on it. And as they say, they reserve time for translating it into french which i can neither prove or disprove of ever happening has anybody seen the c++ standard in french does that exist i don't think i don't think so but i'm unaware of anybody trying to trying really hard to get their hands on it so let's say there's a very small percentage possibility

that such a thing would be actually produced. I just feel really sorry for the person who needs to translate things like elaborated type specifier into French. No, of course. But that's really beside the point because it doesn't actually matter. So this happened, the same thing happened with C++20 and I think 17 and probably with 14 as well. Our convener explained that in all of those cases, the actual publication by ISO happened in the beginning of the next year. And he has thus far successfully convinced ISO that it makes no sense and it's just an embarrassment to ISO if they publish the document

with the wrong year number. So our current expectation is that he will succeed in that convincing again and the official document will indeed have 2023 as the year number all right well that's cool thanks this is this is usually a case where the house isn't really on fire because we have been in this situation before so i don't think there's anything to worry about. We are all calling it C++23 anyway, and it's usually just a matter of a bit of explanation to ISO to convince them to do the same, regardless of the actual, let's call it a physical publishing here. All right, so nothing to worry about.'s good let's move on um our friend

matt gotbold has a new video on computer file and so computer file is a popular youtube channel about everything that has to do with computers and it's actually the first time that matt gotbold actually appears on that channel and his video is called machine code explained and it's just 20 minutes it's only 20 minutes long but it's absolutely brilliant he basically explains how computers work from the ground up and how like like the the instructions what are they doing in the cpu and you know what machine code is and all of that stuff so this is great i recommend everybody watch it i think this is the kind of stuff that you know everybody studying computer science need to see uh rather than you know learning java or something This is really good stuff. Yeah, Matt's an asset. He really is.

Everything he does is marvelous. Compiler Explorer aside, if it was just Compiler Explorer, you'd think, wow, you could just sit back and relax on that. But he keeps going. He just keeps churning out great stuff. And I'm delighted he's in the community.

Does he actually explain how pipelines work, how caches work? Yes, yes. I mean, I don't think he's going into caches. Like, it's just 20 minutes. Yeah. I don't remember if he goes into caches. But, like, yeah, it's pretty good. So, yeah, I put the link to the video in the show notes. And I recommend everybody check it out.

Next news item is our friends from PVS Studio, a static analysis tool. They have a new C++ quiz. They usually do lots of these kind of little community stuff on their website. So they have a new C++ quiz, which has 18 code fragments. Each of these fragments contains an error, which you need to find.

It's a lot of fun. At the end, there's a detailed description of what's actually going on in each fragment. So if you like weird C++, that's a new cool thing you can check out. Yeah, I just went through this quiz when you sent me the document saying, hey, this is what we're talking about today.

It's a good quiz. A lot of it is people going, oh, why did you do thread safety? Everyone gets thread safety wrong. Everyone forgets that code can be thread safe or should be thread safe and might be running in multiple threads. It's things like that. Or things like memset not being called because it's at the end of a function. So what's it matter calling memset on a local variable? The local variable disappears off the stack anyway. All sorts of interesting gotchas like that. Threads and security, that's where people tend to fall over with programming nowadays, I find.

Yeah, I didn't try that quiz. I wonder how well I will actually fare on it. It's embarrassing, isn't it? You get to the end of that quiz, you think, well, I scored 12 out of 18. What am I doing on the committee? Yeah, I failed miserably at some of those quizzes in the past, so I know the feeling.

Okay. Yeah, I failed miserably at some of those quizzes in the past, so I know the feeling. That fail, I'm probably going to try it just out of curiosity. All right. So I have just a couple more news from meetups and conferences. So I got a message from Ben Franzdale and Evan Denaxis that they're bringing back the Boston C++ meetup, which has been on hold for quite a while. They announced that they're going to have a meetup on Tuesday, the 6th of February, which is less than a month away,

in Somerville, Massachusetts, hosted by Formlabs. So the speakers include Ben and Evan themselves, as well as Daniele DeFrancesco and Pablo Halpern. So they have a pretty good lineup there. So if you're in the Boston area in the US, you're welcome to join. It's really cool to see this meetup go back into action again. So I'm going to put a link to that in the show notes. And also a piece of news from a conference, C++ Now, which is the C++ conference in Aspen,

Colorado. They will be back in 2024. They have announced the dates. It will take place 29th of April until 3rd of May. So it's a bit earlier in the year than before. They are looking for sponsors and volunteers. So if you're interested in either sponsoring or going there as a volunteer and getting a free ticket,

go to cppnow.org. The call for submissions is not open yet, as far as I can tell, but I guess it's going to open soon. Oh, actually, I'm looking at the website now, and since I have been putting together the show notes a couple days ago, the call for submissions now actually is open as of today. And the deadline, I'm just looking at the website, the deadline is 9th of February so that's also

just a month a month away and they say that the program is going to be online on the 4th of March so yeah if you want to go to Aspen submit your talk it's a brilliant conference very very special yeah I've not been to C++ I've not been to C++ now I think

it's the only regular conference I haven't been to c++ now i think it's the only only regular conference i haven't been to one of these days i should go i do like colorado yeah you should go higher and higher and the air gets thin the air does get thin i think was it 2019 maybe i gave a 90 minute talk there and i almost passed out in the middle of the talk because there's literally no air to breathe it was like early in the week so i hadn't adapted to the altitude yet and i was talking and talking and talking got really excited and i was like off like i'm passing out and i was like sorry i need to stop talking give me a break like in the middle of the talk so yeah schedule your talk for like towards the end of the week and then it's easier. All right.

So this concludes the news items for today. So we can transition to our main topic. And our main topic actually goes back to another piece of feedback that we received a while ago. So one of our listeners suggested that it might be good to have an episode about Qt. And yeah, I agree. That's a very good idea.

Qt obviously is a very popular application framework in C++, cross-platform application framework. It's been around for something like three decades now. It's been used by hundreds of thousands of people in almost every industry where people use C++. It's certainly a very, very important part of the kind of C++ ecosystem. And actually the last time we had a Qt episode, I mean, we've been mentioning them in news items

kind of like here and there quite regularly, but last time there was a CBPcast episode dedicated to Qt, it was actually four years ago. So it's about time. But actually in particular, the feedback was that we should have some material on Qt and modern C++. So how is Qt adapting to the new stuff, C++20 or even C++23? Do they plan to adopt any of those new features?

What does that mean? What does that look like? And people are interested in that. And so as it turns out, I actually know just the right guy for that to talk about those things. So I asked Wille if he wants to come onto the show, talk to us about Qt and modern C++. And Wille has been active in the C++ community

for quite a while doing really great work, but somehow never has been on CppCast. So I decided we should rectify that. And luckily Wille said yes. So thanks again, Wille, for joining us today. It's a great honor to have you here. You're welcome. My pleasure.

So you work at the critique company. What do you do there? I actually do Android development. Right now, I'm working on a code generator that takes Java class APIs and generates C++ classes out of that. There's all kinds of customers that want that because they want to write predominantly C++ code, but they want reasonable and easy access to the Java APIs, the Android APIs, some of which are such that we don't necessarily have Qt wrappers for those interfaces. And they don't really want to use the Java native interface for that

because it's relatively low level and clunky. And it's tedious to use. We have helper APIs for that. There's a class called QGANIObject that makes it a bit easier. But there's still much better ways to write the code when you get actual C++ classes

that represent your Java classes. So there's all kinds of nifty things we can do with a code generator. So is it basically that you write C++ that then calls into Java that then calls into C++? Well, I mean, the generated glue code basically does the underlying JNI calls for you. But yeah, I mean, the underlying implementations might be such that the that you can just write code that looks all like C++ and there's very little remnants of any Java-like things in it. We'll see how far that goes.

There's, of course, the possibility that you may have an odd J object here and there that you then pass to the constructor of your C++ wrapper. But hopefully it will open new avenues for interfacing with the platform Java APIs. It's, of course, something that's potentially generally useful as well, not just on Android. But I don't think we realistically have other users of C++ Java hybrids in our user community and customer base of Qt.

So in that sense, it's kind of Android-specific. But it's a nifty problem to work on, considering that it's interfacing to fairly different programming languages. Yes, yes. We had, a while ago, I was working on the Juice framework, and that also supports Android, so there was a lot of that there as well and then later i worked at jetbrains where obviously a lot of the code base is written in java and in kotlin but

then we also had c++ stuff kind of on top of that or next to that that had to interface with it so uh it's it's i think i mean more common problem that then you would think that you have to interface between c++ and Java in interesting ways. But obviously with Qt, it's like, I guess, on a bit of a different scale. Yeah, there's all kinds of customers that use Android as an operating system for the various gadgets. So it's useful to provide better better ways to interface with whatever arbitrary java apis you might have on the system so before we get into like super

technical stuff um is there any news like from the qt world that you can share or what's what's kind of the latest exciting stuff that's going on there? I know that the QT World Summit was just over a month ago. I don't know if you were there or anything particularly interesting happened there. Like what's the hot new stuff in the C++, sorry, in the QT world right now? Well, I'm not sure whether I'm actually aware

of the headline news. I did notice that we have some interesting technical additions. We have much better support in recent Qt versions for WebAssembly. And I do tend to play with that myself, like in a dogfooding sense. We have some new libraries that have been added, like a remote procedure called Framework. Well, it basically does protocol buffers and a bunch of other things. Excellent.

But I'm not sure whether those things really count as the so-called marquee features. But I paid attention to them because they were technically interesting to me. Yes, yes, I'm the same. The things that you care about are the things that inspire you, aren't they? Yeah, and we had earlier technology previews of the WebAssembly support where it was basically single-threaded, and I don't think it was able to do nested event loops,

which you sometimes need to do. But the current version is multi-threaded. It has support for all kinds of nested event loops. It can asyncify pretty much all of our APIs that I have tried. And I actually have run into this in a particular educational project I have been working on where I need to provide these pseudo-synchronous APIs that still keep the event loose running so that you can do a fake

blocking wait on a button or a timer. It doesn't need to target web browsers, but since I was working on it, I thought, well, what the hey, I can just as well try running that code on a browser

and it all worked out of the box once I used the right kind of link or flags for the WebAssembly target build. Yeah, one of the great things about Qt is its breadth of support. I started using it myself almost 20 years ago when I was working on Total War. And I was enormously impressed that it seemed to just work everywhere. We were considering writing our tooling on Mac and on Linux

and obviously on Windows. And of course, all of those, they're running on different compilers. Which versions of the standard, which compilers does Qt currently support? It must be a huge set. Well, I mean, Qt 6 is targeting C++ 17, and it requires C++ 17.

That's relatively new, though. I remember it was requiring C++ 11 for a while. That was Qt 5, yes. But ever since Qt 6 has been out, and well, we are right now getting out the beta releases of 6.7. So there's been six releases of the Qt 6 release series already, and it was baseline with C++ 17 from the get-go. So was there anything about C++17 that made you, made Qt decide, right, we're going to upgrade to Qt 6,

we're going to pin ourselves to C++17? Not really, actually. It was more like staying current with the times upgrade. I don't think there was any particular highlighted market feature that suggested that. But we did want to have a reasonable baseline bump since I think C++11 was introduced as a requirement in the middle of the Qt 5 series. It wasn't a requirement from the get-go. But for Qt 6, since we are going to live with it for a couple of years, we did want to bump

as high as we can reasonably. But since this happened a while ago, I mean, we are talking two years ago, we couldn't quite bump the baseline requirement to C++ 20. It's still experimental in various implementations. And we target some real-time operating systems where the RTOs, vendors, toolchains

are not quite up to speed with C++20 yet. But you could compile with C++20, right? I guess you have to be able to compile with C++17, but you could compile with something newer so that the client, like not in the QG itself,

but on the client side could use newer features, right? So you kind of have to keep up with all of these newer standards and probably a lot more compilers probably than just the three major ones. So how do you keep up with all that? So we do make sure that the stuff works with C++20 because we want to make sure that the stuff works with C++20 because we want to make sure that

application developers can use a newer standard and use all of our stuff with it. That's not necessarily always tested automatically for the newer standard versions. We have a palette of

continuous integration configurations that check our stuff on a variety of platforms. I think it's something like 42 different builds that we do. So there's multiple Windows builds, a bunch of Mac builds, a boatload of different Linux builds. There are some of those RTOS builds that happen as part of the sort of official always on automatic tests for all of our changes.

We do have WebAssembly builds there as well. So that's a properly supported platform. Oh yeah, iOS and Android too. And different compiler versions. So it's something like 10 to a dozen compiler versions altogether. I think maybe more if we count all the variants of the embedded targets and the real-time operating systems. That's a large set.

Yeah, and it's been something that we have improved over the years. So we have a rolling roadmap for it, how to update the systems that we use for that kind of continuous integration. So we keep up to date with what Red Hat versions we use, what Ubuntu and OpenSUSE versions we use, and also for updates of the macOS versions, Xcode versions, and the Visual Studio versions on Windows.

One thing that Qt is a large library and it is doing a lot of work to stay compliant with modern compilers and contemporary C++. The big elephant in the room, though, obviously, is modules.

Modules is enjoying partial implementation in various compilers. What do you think about C++20 modules and their adoption and how it might affect you? Well, we haven't really done even the early stages of attempts to change Qt to be modularized in that fashion. But it's certainly in the vague plans. We use CMake as our build system everywhere. And the proper support for C++20 modules in CMake landed weeks ago, if I remember correctly. There was a blog post that said that the CMake and GCC combination now works,

but that required a trunk version of both CMake and GCC. So it looks like from our perspective, it's certainly becoming a reality. And we do want to adopt modules in various ways because there are interesting things we can do with them. We could do, for instance, various people always keep asking whether we could do like a better unity build build everything you need but for a custom application scenario so you could drop out things

that you don't need and we could we could do that sort of stuff with with modules because the uh basically the compiler is going to drop everything it doesn't end up finding ODR uses for. So whatever your application doesn't use would get rather neatly dropped. And that

would be an improvement over the traditional ways of doing Unity builds, like include everything everywhere and compile it all in one big huge shebang. That's, Kai, that's what you gaming people are doing, isn't it?

Oh, yes. So the last code base I worked on was many millions of lines of code and many tens of thousands of files. And Unity builds are the only way really to completely, you know, to quickly build. The difference between using Unity builds and using loose builds,

as we call them, we're looking at orders of magnitude. We can get a Unity build out in seven or eight minutes, sometimes five on a good day, whereas a loose build would take well over an hour. In fact, I think we got to the stage where we didn't even try loose builds for so long that they no longer worked because one problem with the UT builds

is that they hide dependencies. There are other problems as well, but the trade-off of rapid turnaround is completely unavoidable. You've got to do fast ideas i i entertain there they are not really about the maximal throughput of the build process but uh like it's more about a combination of getting a throughput in improvement without completely losing information of your dependencies and losing information or losing the modularity of your code.

So that's another very attractive property of modules because at least in Qt base, we have all sorts of metaprogramming trickery, including macro metaprogramming and that sort of stuff so with modules it's it's much easier and more feasible to tame that kind of complexity and sheer ugliness of your code because you don't you don't have to do that much trickery as you have to do with the traditional header model. You can just hide utility macro gunk so that it doesn't leak into your so-called client's code.

I'm certainly looking forward to making the best use of modules, but I don't think I'm ready yet. Maybe my tools aren't ready yet. I'm certainly looking forward to making the best use of modules but I don't think I'm ready yet maybe my tools aren't ready yet I'm still waiting there have been all kinds of pessimists about modules in general I'm to my own surprise as well somewhat more optimistic about that it was to me always clear that it will take time for build systems to accommodate them

and especially to get them working everywhere for all users who either really need to use them or just want to play around with them. They are not going to necessarily fit all the use cases that we have for various existing scenarios. I mean, it's not going to be magically faster than your Unity build if you need to build everything anyway. You would first need to build the module

and then build the code that uses it. And that's splendidly fast, the reading, the import of a readily built module. But that doesn't necessarily mean that it's faster than any other approach. But overall, I'm somewhat optimistic that we are going to get more of that stuff into the hands of more users relatively soon. And in a couple of years, we might get ever closer to the idealistic dream that we can look back at the way we did legacy things and laugh about it. As in, ha ha, you had those problems with the textual inclusion. And those are just prehistoric problems that nobody has nowadays. Yeah, well, let's hope you're going to get into that world.

Actually, the modules question, I think, was the number one question in those emails that we received about people wanting to hear about Qt that was the number one thing like are you going to support modules it feels like there's like a three-stage like evolution here right first you need the compilers to support it which kind of the three major compilers now do but that's not going to help you until the build system that most people nowadays use i guess cmake is the most popular one or like the other popular build systems that we have so those build systems need to like use modules and it seems like we just got there now but that still is not going to help you because if you are using cross-platform

frameworks like qt and or other things like that like they need to support it too and and once you get there i think once like the really popular frameworks and libraries kind of come with module support, I think then we can say that, yes, we managed to actually adopt this new feature. Yeah, but we talked about modules a fair bit in the corridor discussions of the most recent Qt Contributor Summit.

So there's a lot of internal desire to get that forward, to do some sort of early prototyping on it and then subsequent steps to actually make it an option to use Qt with C++20 modules. That's, of course, as is the case with everything related to Qt 6, it needs to be an additional thing. I mean, we are still going to keep the library consumable by C++17 applications.

And I suppose that's one of the problems that we have with modules is there's going to be a time, there will be a period where libraries will need to ship with header files and with modules simultaneously, and they'll need to stay in sync. Well, that's going to be like the next decade, isn't it? Yeah. Yeah, who knows how long. There are solutions to those problems i mean um i mentioned the ability

to hide hide ugly macros uh that that kind of stuff really only works if if you have the so-called strong ownership model and we had committee debates on whether the strong or the not so strong ownership model would be the right thing to have and it seems like there's a growing consensus that the strong ownership model is the right one and it looks like implementations are converging on that point. So GCC originally had the weak ownership model in its implementation. That has been changed. I got the impression that the similar change was done to Clang as well. I'm not 100% sure of that, but I thought the same guy made the same change to both gcc and clang

and uh msvc has always always had the strong ownership model so but uh so that that model of course needs escape hatches and you need those escape hatches in order to make sure that your code works either way, regardless of whether you use textual includes or module imports. Of course, for that, there are alternative strategies. You could just write your headers so that they actually end up importing the module. That's what some of the field experience gathered by Microsoft suggests doing here. But I think there are also alternative strategies

where you can actually do the textual inclusion and it will end up getting the same interface and the same semantics. All right. So before we continue our discussion, I'd like to, we have a message from our sponsor. So this episode is sponsored by Shaved Yaks, getting all your yaks in a row.

Shaved Yaks brings you some of the community's best events, C++ on C, C++ online, and the ACCU conferences, as well as SwiftCraft. They can also help you with your own conference management, whether through software platforms, partnerships, or just advice. And if you're looking for training and test-driven development for C++, core routines, or effective C++, they have that covered as well. Go to shavedjax.com to find out more. All right, and with that, we're back. Let's move on from modules, although it is a fascinating topic

and we could keep talking about this forever. But there is more happening in the C++ world. There are more kind of big, interesting, exciting features that were either released in C++20 or C++23 or that are slated for C++26, which is currently in development. And one of those is senders and receivers. And I want to call that out because, Vila, I've actually seen you in the flesh a few

months ago. You were so generous to travel to Helsinki and speak at our meetup there, where you gave a talk about senders and receivers and how Qt can integrate with them. And so that's a very new feature, which isn't even in the standard yet. It's still in development. But maybe you can still give us a little bit of an overview, you know, what they're for, why they're really cool, and whether we will get them in CSS 26, and how Qt will integrate with those, and why that's a good thing.

All right. So how to? Yeah, that's a good thing. All right. So how to? Yeah, that's a big question. I'm not sure. But well, I mean, we can easily start with the bold claim that I use in the titles of those talks. So they basically say that senders and receivers are the future of asynchrony in C++,

which basically seems to be what we have agreement on, on the design level in the committee and in library evolution. So they provide a generic framework for all kinds of asynchronous problems. The idea is that it provides a set of concepts and all kinds of utility classes that allow pass data from asynchronous workers to the continuations. So basically, the senders are a representation of asynchronous work. It's almost like a task, but not quite, since you can control where the senders run and where they complete. Receivers are pretty close to what you would have as a continuation.

But then on top of these basic concepts there's a algorithm layer that basically allows you to write real continuations so so between a sender and receiver there's multiple channels for signaling successful completions erroneous completions and cancellations. But for simple programming tasks, you can just write code where you're interested in just, say, the successful completion. So then you can just write a simple lambda continuation that you tie into a sender. And I guess another part that should be mentioned is that the framework conceptually works

so that you first build your work graph in a single-threaded fashion. So you set up the execution context transfers, all the continuations, that sort of things, even data transformations, if need be. And then you start running the whole graph once it's set up. So it avoids the problem of having to worry about concurrency and asynchrony when you're doing the connections, building the graph, what

runs where, where the continuations run, like launch work on a helper thread, get a continuation and run it in the UI event loop in order to update your user interface. So you can describe that kind of transitions without doing multi-threaded code when you're doing the description. And then you just run that whole graph and it starts pumping things around. Yeah, this kind of matches my very rough understanding of it. You kind of define the topology of like, you know, here's a callback that calls this or whatever.

This kind of topology of like multiple things calling each other asynchronously. And you kind of separate that from where it's actually going to run and what's the work that's actually going to run there yeah and it it neatly uh separates the actual payload code the business logic code that you have from the orchestration so you have the uh asynchronous tasks what whatever responsibility it has uh that's separate from where it's actually actually scheduled to run. So whatever you run in that helper thread is not aware necessarily at all that it runs in a helper thread. And it doesn't care where its continuations run. It just, the only responsibility that task really has is to complete with one of the three possible outcomes

and well there's more than three because you can have multiple signatures of an error completion and a successful completion that you can have but nevertheless it just completes with those and then separate algorithms that are generic and reusable can then bind whatever arbitrary continuations, and then those continuations can be sent elsewhere into other execution contexts to run. So it's relatively straightforward to do something like go to a helper thread, come back to the UI thread, go to another helper thread, and then come back to a UI thread. And you can just build that topology, as you said, in a single threaded fashion and then run it. And it will just do that ping pong between threads very easily.

You don't need extra synchronizations when you just pass things by value through the completion channels. And it makes it rather easy to program that kind of stuff. And that's one of the main ideas, that it's trying to encourage the notion of what its designers call

structured concurrency. It's trying to manage the complexity of asynchronous programming and make it palatable and feasible. Has either of you been uh keeping up to date with this like what's the status of this is going to be in css 26 because i think last time

i checked they were still arguing about like what should or shouldn't be part of that api and like like reviewing it and stuff uh yeah i mean i have i have participated in that work via various proposals and stuff like that. So it's still in design review, mostly because there's proposed design changes. The main author proposed some relatively significant but not earth-shattering changes to how you customize algorithms in it right and there's there's another uh proposal that i have in the i have in the pipeline for changing how you how you do the things that are not really customizations as such but adaptations to the framework so that you can actually write your own type that is a sender or write your own type that is a scheduler

and how that is done. So the gist of that proposal is that we get rid of the idea of using free functions and argument-dependent lookup and use member functions instead so that simplifies the model quite drastically and removes the uh the the bogeyman of of adl from the picture yeah some people don't like member functions and they prefer to do stuff with like more in a more functional way but i guess guess you're right. It makes things simpler. So it's good to know that this is still ongoing.

I really hope that you're going to wrap this up in time for CSOS 26 because I think this came out of the work that used to be called Executors. I think it's been in development for quite a while. It was supposed to be in 23 or even in 20. So let's hope it's going to conclude. Yeah, the current target for what's there as proposal form is C++26, certainly. So if all goes well, that's where we are going to hit. But there are future extensions in the pipeline already. I mean, we are going to

be looking at streams and once the basic stuff is in. The ones we have right now are one-shot operations, so we need to extend those into streams and models. Right. But of course, the reason we're talking about all of this is because you said that actually there's a really nice way how Qt can integrate with that framework. Is that right? Yeah. has a scheduler concept, which is basically, it needs to be an execution context that can trigger the running of arbitrary work, meaning that it doesn't need to directly run arbitrary work, but it needs to be able to run notifications that basically don't do anything.

So it's like a function returning void that has no arguments. So that's a basic requirement for a scheduler. And it just so happens to be that the event loop in a Qt thread, the Q thread, is just such a thing. The event loop can be convinced to just trigger a notification. So when you do that, the notification, of course, runs in that separate thread, and then you can sequence custom work on it. And that basically makes the whole model work, that you can queue your custom work and its continuations

into that triggering of the work in whatever execution context. So I think it was roughly a year ago I decided to take a stab at adapting QThread into a scheduler in this model and then I realized that I can just as well also adapt any queue object signal into a sender. So I wrote a prototype implementation of that, and that's what I have been showing in those talks and presentations, both in the Helsinki C++ meetup and an earlier one in CERN in Switzerland, and a whole bunch of internal presentations, and also one in the QT Contributor Summit a couple of months ago.

So yeah, it ties the conceptual and generic and abstract model into something concrete. I mean, you can run that sort of sender and receiver code using actual Q threads and using the Qt's user interface event loop. So it gives you the missing bits that are not in the standard proposals yet. We don't have all that many concrete schedulers there, but all application frameworks do if you do a little bit of adaptation. And that's exactly what I did on top of Qt.

It's still under wraps. I haven't put it into any publicly visible repository. But the plan for this year is that once I'm sufficiently done with that Java API to C++ code generation that I mentioned, then I'm going to basically put all my daily efforts into actually shipping this stuff as part of Qt. It's probably going to need to target 6.8 or 6.9, but nevertheless, it's going to be something that I'm going to work on finally getting out so that people who are interested in this stuff can actually use it.

You're going to need a C++20 compiler that has concept support, but that stuff works fine. We have those compilers available. Yeah. So I'm loving this, but are there any other, you know, contemporary or even future C++ features that Qt integrates with or that you're planning to integrate with? I mean, how are you going to be making use of contemporary C++

and future C++? Well, one of the big motivations for reflection is that we would all i mean qt users and qt developers to some extent we would really like to get rid of the separate meta object compiler that we have yeah so that's that's a long-term pipe dream uh the i don't know how your how much your audience is up to speed with these things you mean like the signal slot uh architecture no i mean i mean reflection as far as standardization goes so we we mentioned it on one of the last episodes as a news item we do want to like do an episode about it because now there's this new proposal which actually now suddenly looks like it might actually be in cso 26 it's actually looks really good and so we might want to like try and get one of the authors of that on the show yeah but i think

that's the uh so the sort of major news item that it it's progressing out of a study group into actual design design review yeah with with the uh with the goal of actually shipping the first part in c++ 26 but well these are these are major things both both the asynchronous stuff and reflection so there's already next stage stuff being planned for C++29. For reflection, we want to enable more of the code injection facilities that have been envisioned and to some extent prototyped. But we want to make that a concrete standard proposal that we can actually ship in hopefully C++29.

So there's a lot of interesting stuff coming through that pipeline. And it's something that interests me a great deal, not just as a way to replace things like separate code generation tools and meta-object compilers, but it does give C++ as a language a whole new set of capabilities that other languages and programming environments have. You can do much better generic programming with that kind of facilities. Yeah, I'm very

much looking forward to reflection. I mean, you're a long-standing member of the committee. What are you doing there at the moment? What's your current work? Are you involved in the reflection proposal or are you just looking from the sidelines? So that's mostly from the sidelines i i have been participating a great deal on the

on the senders and receivers effort uh writing modification proposals and things like that for it i i'm basically the uh a major guilty party to not having networking in C++23 because we had the whole debate over which asynchronous model to go with. And I convinced the design groups to have a conceptual split between the order executor and the current scheduler concept. And we ended up going with just the scheduler concept, so we no longer have the other one. But in addition to that, a fair amount of my time is in the study group

that's co-chaired by Timur. So contracts have been a major time thing for me. Oh, my. We have been having all sorts of lively discussions of how to ship a minimum viable product of that stuff in C++ 26. Yes, I think it's the other, apart from reflection, the other big feature that actually looks like will

be in C++ 26, because we're almost ready to pass it on to design review to the next stage. We just have to clean up a few little things where we have quite reached agreement yet on how something should work. But it looks really good. But it was a lot of hard work over the last few years yeah it's kind of funny how these things go uh c++ 20 have a lot of stuff loaded onto onto the c++ 26 screen and uh it's it's not like that was exactly a planned cadence of any major or minor switch

between the standard versions, although some people like to think that it is, but it's really not an official plan. So maybe it's just so that after getting major stuff out, it takes a while for the proposal authors and other people to figure out how to get the next major thing out. Of course, one would hope that eventually we'll figure out a way to stop shipping so many major language features over time.

But I don't think there's an endless amount of those. I do agree. One thing I've observed about the standard over the past eight years I've been working with it is that the standard is made up of the things that people bring to it. People bring proposals, the committee goes,

that's interesting, let's take a look at that. And that's what ends up in the standard. The future is written by the people who are there that's basically the um mo of of iso's standard standards committees that uh and any any expert member can bring forth a proposal and the committee needs to look at it so people are surprised when I tell them that COBOL is still under active standardization. You know? Fortran as well.

Ada. There's still a working group devoted to those languages. The participation is quite as high as C++, C++. We had 250 people at Prague and we're lucky to get 10 on Ada.

Yeah, well, we could, of course, visit them and talk to them about reflection and coroutines and generic asynchronous and see whether they would be interested in that sort of stuff. But I'm not personally going to join any more language standards committees. I relatively recently became a member of the C committee as well. And that's wide enough to be a member of two. So I'm actually going to be very careful to avoid commenting on the COBOL or FORTRAN standards, lest I'll be made a member of those as well. Be co-opted, yeah.

All right. So we talked about Qt quite a lot. We talked about your work on the committee and how C++26 is shaping up to be a pretty big release again. So I guess the last question I want to ask you, is there anything else going on in the world of C++ that you find particularly interesting or exciting that noteworthy in some way? Whenever this question has come up in the last eight years or so, I've pretty much always said that reflection is splendidly exciting enough.

Yes. Because it gives us so much expressive power and functionality that we've never had before. And one of the most attractive qualities of it is that you can take quite a bunch of facilities that we have had as proposals and that we have actually adopted as language facilities and expressed them in terms of reflection and code injection. And what that actually gives us is that we can write reusable functions at a completely different level. And that ends up doing something that was a major part of the motivation for the metaclassics proposal that Herb Sutter wrote,

that you can actually move grand portions of the language facility implementation from the inner guts of a compiler to actually reusable library functions. And that allows you to compose those library functions in different ways. So you don't have to just have a particular facility that's specified and implemented in a compiler in a particular way, you get much more flexibility when you have the so-called

building blocks available as reusable code, and then you can do different kinds of compositions of them. I think one of the examples of that is that when we were talking about the whole member access operator, the operator dot proposal, there was a lot of discussion about

which kinds of members it should prefer and where it would need to look and when for fallbacks. And you could just write custom approaches of that when you have the right kind of building blocks exposed via reflection. It's basically answering the age-old question of, okay, I have that class over there.

I would really like to reuse its interface and its implementation. And the way you can do that in C++ currently, the only way is to just do public inheritance. But when you have reflection and code injection, that's no longer your only option. You can expose the same interface in your class as one of your composite types does. So you can just literally reflect an interface

of a data member on your class. So that's why it opens completely new doors in how you actually design your types and abstractions and APIs. Because there's no longer that strong suggestion that, well, if you want this type to behave like that other type, you have to use public inheritance, in cases where you really really wouldn't want to so yeah that that is a big item and it's it's absolutely fantastic that we are finally making concrete progress on it so that it progresses further further onwards from the study group yes that is really exciting and we will have an episode on this soon hopefully with one of the authors of that proposal uh we could talk for hours about all of these things of course

here but we have to wrap up now because we are kind of out of time um so before we do that really is there anything else you want to tell us for example how people can get in touch with you if you want to talk to you more about qt and modern c++ and reflection or anything else yeah i mean my my email address is will.votelion at gmail.com if if people want to ask me direct questions i i must of course warn aspiring uh correspondents that i get a lot of email from the standards committee reflectors and and from from work email sources as well but I do tend to operate based on the principle that in Hogwarts help will always be offered for those who ask for it. So if you ask nicely and have an interesting problem,

I probably won't be able to resist the temptation to help solve it. Well, that is very, very kind of you. So, Ville, thank you so much again for being our guest today. And, Guy, thank you so much for being my co-host. Absolutely delightful. Thank you, Tina. It was a pleasure to talk to both of you. And, yeah, have a great rest of your week and see you next time. Likewise.

Cheerio. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in. Or if you have a suggestion for a guest or topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate it if you can follow CppCast on Twitter or Mastodon. You can also follow me and Phil individually on Twitter or Mastodon. All those links, as well as the show notes,

can be found on the podcast website at cppcast.com. The theme music for this episode was provided by podcastthemes.com.