CppCast - Belfast Trip Report

Episode Date: November 14, 2019

Rob and Jason are joined by Timur Doumler. They discuss some of the news that occurred at the C++ ISO meeting in Belfast where the committee responded to some of the National Body comments on the C++20 draft. Timur also goes over some of his proposals and the progress on adding an Audio API to C++. News Maryland C++ User Group 2019-11 Belfast ISO C++ Committee Trip Report p0593r2 - Implicit creation of objects for low-level object manipulation Trip Report: Autumn ISO C++ standards meeting (Belfast) Links CppCon 2019: Timur Doumler "Type punning in modern C++" Timur Doumler — Initialisation in modern C++ CppCon 2018: Timur Doumler "Can I has grammar?" p1386 - A Standard Audio API for C++:Motivation, Scope, and Basic Design p1774 - Portable optimisation hints p1912 Interconvertible object representations Sponsors Write the hashtag #cppcast when requesting the license here One Day from PVS-Studio User Support JetBrains

Episode 223 of CppCast with guest Timur Dumler, recorded November 13th, 2019. 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. And by JetBrains, makers of smart IDEs to simplify your challenging tasks and automate the routine ones. Exclusively for CppCast, JetBrains is offering a 25% discount for a yearly individual license, new or update, on the C++ tool of your choice, C-Line, ReSharper C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at www.jetbrains.com. In this episode, we discuss news from the recent Belfast ISO meeting.

We're joined by committee member Timur Dumler. Timur tells us about some of the changes that first podcast for C++ developers by C++ developers. I'm your host, Rob Bervink, joined by my co-host, Jason Turner. Jason, how's it going today? I'm all host Rob Burfing joined by my co-host Jason Turner. Jason how's it going today? I'm alright Rob. You know you just said episode 223 and reminded me that I am getting perilously close to episode 200 of C++ Weekly. Yeah we're only like 20 ahead of you now right? Yeah I'm at 193 I think so I've got Southern left and yeah. Okay.

Episode 200 will be basically December 30th that That'll be the end of the year. Just round it out perfectly here. So I was looking at it recently to see like how many episodes we're averaging a year. And we usually seem to miss about four or five. So we probably still might have like three or four years until you catch up. Maybe even five years. Yeah. You just keep getting closer and closer

yeah okay the top of every episode i'd like to read a piece of feedback um this week i got an email from eric richardson uh it's a long email so i'm just gonna read part of it but he says uh rob and jason i started a new job in february and began listening to your podcast on my daily commute about a month ago i started looking around for local C++ user groups, but failed to find one in the Maryland, D.C. area. After posting about potentially starting my own on the Slack local groups channel, I got some encouragement from John Kalb, Phil Nash, and Jens Veller. John also mentioned that Bob Stiegel from the C++ committee was looking to start one in the area. If I was all the way caught up with your podcast, I would recognize his name by the time I hadn't gotten to that episode yet. To keep it short, he started the Maryland C++ User Group, which is CPP Maryland,

and I will post a link to that on meetup.com in the show notes. And he did reach out to Bob Stiegel, who's helping him run it. And their first meeting is going to be Wednesday, December 4. So if you're in the, you know, Maryland, Washington, DC area, and you are listening to this podcast, you should definitely go check out their first user group meeting on December 4. I think I have it up there. I'm talking about linear algebra and the ranges in C++ 20. And you know, in that general area, and i know it's an area that's hard to navigate with lots of traffic you know yeah the beltway kind of northern beltway area but you know that there are thousands if not tens of thousands of c++ programmers in that area because

contracting yeah easy so hopefully they'll get some people coming to this and be able to start to build a community there. That'd be great. Well, it looks like they already have 60 members, 62 members on the user group. Wow. They already managed to find some people. I mean, they haven't had a meeting yet. Right.

You just emailed me recently, and to have that many people signed up before the user group even has a meeting seems promising. It does. That sounds great. Yeah, hopefully they'll get some traction. Yeah. Okay, 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 cbcast.com. And don't forget to leave us a review on iTunes and subscribe on YouTube. Joining us today is Timur Dumler. Timur is a C++ developer specializing in audio

and music technology, active member of the ISO C++ committee, and part of the Include C++ team. He's passionate about building communities, clean code, good tools, and the evolution of C++. Timur, welcome to the show. Hello, thanks for having me. So before we started recording, you mentioned that you've been traveling for at least three weeks now. But I don't I think you and I have basically been at every conference that I've been to this year. We've been to at the same time. That might be right. Yes. You were at Core C++. Yes. Did you go to TechTown? I did not go to TechTown. I did go to Aspen and C++ Now. I was at CppCon. I was at CppOnSea.

Oh, C++. Yeah, okay, yeah. That's it. That's only three conferences. Right. That's so far. That's a lot. So, yeah, the last three weeks were a bit crazy.

So, I started with C++ Russia in St. Petersburg, which had a really nice lineup this year. I mean, obviously, for me, it's special because I Russia in St. Petersburg, which had a really nice lineup this year. I mean, obviously for me, it's special because I'm from St. Petersburg, but they are more and more doing a really international program with lots of English-speaking, very well-known speakers, really good program. Then I traveled from there to Belfast, where we had a C++ meeting, a committee meeting. Then immediately following the meeting, we had a mini ACCU conference, also in Belfast, which was Monday, Tuesday.

And today, I just arrived in Berlin for a meeting C++, which starts tomorrow. And did you speak at the ACCU meeting also? Yeah, yeah. I had a talk there about class template argument deduction. So here, I'm giving a talk about tomorrow, actually, about

kind of all the new stuff in C++20 like an overview or kind of the smaller little language features So yeah, really excited about that Wow, awesome But a bit too much traveling so I definitely need to cut down on the conferences next year and actually

get some work done Yes, I've been thinking about what conferences I'll be going to next year and i've heard other people on twitter talking about you know going to the conferences that you know like having to decide which conferences you go to you can't go to all of them all of the time yeah yeah i learned this year that this is completely infeasible and yeah you need to choose okay well timor we want to definitely uh to you about the Belfast trip report, Belfast meeting last week. Could you maybe start off by giving us some of your highlights to come out of that meeting? features happening or some drama happening, like last time we pulled contracts and things like that. This time it was very different because we are now in the

phase where we are just kind of bug fixing. So we released a committee draft for C++20 at the last meeting in July. So now we are just processing what we call national body comments, which are basically bug reports. And we have this meeting and the next meeting in Prague just basically

to fix these bug reports and finalize C++20. So it was nothing really big happened. It was just a lot of collective bug fixing. But I have to say that some of these bug fixes resulted in interesting fixes. I think my highlight was there was one comment that the way we introduced class type as non-type template parameters via the spaceship operator where you have a defaulted operator equals equals. It didn't quite work. The resolution is really interesting.

So now we actually completely redesigned how a non-type template parameter will work. So the first big news is we're going to get in C++20 floats and doubles as non-type template parameters. And so currently only integral types and compound types that contain integral types?

No, just integral types and pointers. Okay. And it will be floats and doubles, which for me is great because we're doing lots of number processing, so you want to compute stuff at compile time. The floats specifically, we have lookup tables or filter coefficients or whatever, we're going to be

going to have more powerful tools to do that but it gets even better. So now we say okay, these kind of integral types and floating point types, we call them structural types, and they can be non-type template parameters, but also any class that has only public members, which are structural type, is a structural type

itself and can also be used as non-type template parameters. So we can use a lot more classes as non-type template parameters with a model that makes a lot more sense than the model we had before. So now we can go and do compile-time strings as non-type template parameters and all kinds of really, really cool stuff. So I think that was my personal highlight in terms of 20. What was the holdup? Why were doubles and floats not allowed as non-type template parameters before? So they're weird. So you can't really define a strict order on them, right?

So how do you order a float, right? So you have all these weird things like nones and infinity. So let me put it another way. So if you have a non-type template parameter, right, what do you need to do? What the compiler needs to do is it needs to figure out whether two types are the same, okay? Right.

So if you have, like, specialization, you need to figure out if that's that specialization or, you know, maybe the primary template. So the compiler has to compare these types all the time. So it needs to be able to really quickly determine whether two types, like template types, are the same. So it needs to compare also the non-type template parameter values, right? But for floats, comparison

is not really as well defined, right? Like, you know that if you compare floating point numbers, you don't really do equals equals, right? Because they're not precise. So, yeah, there's a lot of problems, but yeah, we decided that, you know, we're just gonna do it anyway and and

then maybe for some cases the comparison is maybe not going to do exactly what you think but we have cases like this already where if you have like a atomic or float and you're going to do like a compare exchange there it's not going to actually do floating point comparison it's going to do bitwise comparison so you kind of have that stuff already um so yeah i mean for kind of meaningful values it makes sense and i think it's highly useful and especially the thing that you can build classes with that as well use them as well i think to uh to break this down for our listeners you can correct me if i'm wrong so like uh so if i've got an array of int that's the type template parameter comma five that's a non-type template parameter that's a vowel

value that says there's five integers in this array right and right we are uh extending that so that it's not just um it's not just integral types that can go there now it's classes it's whatever you want basically yeah so you can write template double x, class whatever. Okay. And then you can write template widget x, and then widget is your own class, and then x is an instance of that class. It obviously has to have, like, a const x per,

you need to be able to construct it at compile time, but basically you can, it's a weird way of, like, trafficking objects into a type via the type system. It's really, really powerful if you think about that. Okay. All right, sorry to interrupt you. So that was your first favorite feature was extension of non-type template parameters. Mm-hmm.

Yeah, so we didn't really vote any features as such into C++20 because the feature cutoff date is long gone. Right, right. So the rest of what happened in evolution where I was most of the time was kind of looking at these NB comments like these bug reports and then basically rejecting most of them because most of them were

pointing out stuff and trying to change the design for modules or coroutines. We made some small changes but not too many. But the exciting stuff happens I think with, not with 20, because it's pretty much done, we're just fixing bugs, but

more like with, so one day I spent in the Evolution Incubator, which is the group which reviews kind of future designs, possible designs, which go into like Superstars 23, or maybe even later than that, and just does like a first pass on kind of more

really new and forward-looking features. And so I had a bunch of papers there myself but also there were other papers from other people which I found really exciting. So we talked about Epochs, which is Victoria Romeo's proposal. Right. And then the one thing that also got me really excited

was a proposal by Hal Finkel to introduce JIT to C++. I mean, this is very far in the future, but he had a really interesting discussion about that. So basically what he's proposing is that you can take a template specialization and give it a template parameter, which is a runtime

value, and then it's going to go off and instantiate that parameter at runtime using a JIT engine. And then you can basically compile code at runtime. And that's really, really powerful. But that's like very future-looking stuff. So in terms of C++20, I think it was mostly bug fixes and B comment resolution.

That's what we were doing all week. So I don't have any exciting features to report. So I'm looking at the trip report on Reddit, and it says the Evolution Working Group looked at about 100 national body comments, about half of which were from modules. What, what types of bugs were,

you know, the national bodies complaining about with regards to modules? And you said that most of them were rejected. You didn't see them as being true bugs. Is that accurate? Um, yeah, I mean,

some of them were like proposed design changes, which we kind of can't really do at this point okay um there were um so the modules day i was actually not uh in the room for most of the day so maybe i can't comment on that that too much there were a few where people were pointing out um yeah so um if you use like uh you know module is like a context uh sensitive keyword but then if you use it in certain places it kind of breaks or like other inconsistencies like that, which we did fix. So, yeah, it's stuff like that. Kind of small fixes.

So the national body comments, the national bodies, I guess, like we're just talking to Inbal about the Israeli national body getting started here. They can submit a comment, and then it's reviewed, and if it gets rejected, like, is there... I don't know how to phrase this, but does the national body have any power after that? Can they still say, no, we refuse to accept this unless you address this comment that we made or something? All right, so now we're in this wonderful land of ISO rules and ISO procedures. So the way this works is basically we have,

so we published a committee draft, which happened after the last meeting in Cologne. And then all the national bodies get to submit their comments. And then we have two meetings like last week and one more in Prague in February to resolve them. And then at that point, the only thing they can really do is, so then after Prague, when we resolved all the comments,

we published the actual international, draft international standard document. And that goes for something that's called a national ballot, where all the national bodies can vote on the complete standard. But at that point, they only get to vote yes or no.

So they can say, so what they can then do if they're really unhappy is they can vote down um like the whole standard that's basically the only thing they can do at that stage but that has never happened and i'm pretty sure it will never happen so usually things are resolved um you know way before that like herb is doing a great job as like running this whole thing and he talks to all the national body heads and he makes sure that really critical issues are discussed way in advance um so yeah that's kind of the procedure is that resolved on like a majority vote when the national bodies vote on the final draft yay or nay

like how does that work exactly i i'm not entirely sure like you would need to ask her but i think if one nation kind of objects to the standard then it basically doesn't happen or i'm not sure what happens then it never happened before so i i don't exactly know but maybe we shouldn't go too deep into that okay that's fine you don't want that to happen we need to we want to release it yeah we want to be and then and then everything everything we're going to be have unanimous consent and everything will be fine and we want you to do this. And then we're going to have unanimous consent and everything will be fine. And we all get to enjoy all these amazing new features that we've been working on for the last three years. Well, I'm curious about your involvement in the evolution groups.

Do you ever find it difficult to stay interested and excited in things that you know that you won't actually be able to use for four, seven years or whatever um yeah well first of all i don't think it's like that anymore so i think um with um 20 we're gonna have i think all three major compilers supporting all the important features within a year or so so they got a lot faster um so that's my prediction um the other thing actually is the other way around like sometimes i'm so excited about stuff that I come back from a meeting, I go back to my day job, and then I start coding. And then I'm using it like a feature, and then I'm like, why does this not compile?

And I'm like, oh, of course, because it's in 20. My compiler doesn't do that yet. It happened to me the other day with how you can take deco type of a lambda and you can default and initialize lambdas and things like that. And I was just writing code and then why does this not compile? And I was like, oh, of course,

because we just talked about this, but it's not really a thing yet. And yeah. Does your job allow you to work closer to the bleeding edge of compiler releases? Yeah, so I'm quite fortunate. So we started writing like a basically new code base, but no, but less than a year ago.

So yeah, we own 17. And so, I mean, obviously we're cross platform. So we need to like be on the, whatever the subset is of the latest, you know, Apple, Microsoft, GCC, but whatever that subset is, that's what we're using. So I think if all three major compilers are going to support 20, then what we're using so um i think if if all three major

compilers are going to support 20 then probably we're going to jump to 20 if nothing comes up which is like a deal breaker it's interesting you just said apple because i've been involved in some conversations recently on twitter about how we kind of need to be treating apple clang as a fourth compiler because it's really hard to tell what features it supports so i find that i mean i like a lot of stuff that Apple does, but that particular thing I find very frustrating. Like, for example, you know, things like std variant or std optional. They're mostly like header-only types,

but then they have like a couple of exceptions that they throw. Like they have like bad variant access and bad optional access, I think. And they have to be defined kind of in a CPP file. Otherwise, you kind of pull all this V tables in your headers. And so then that doesn't compile on macOS. So on macOS, we don't have variant and optional because it depends on the dynamic library that the macOS, that ships with macOS.

And so even though the compiler doesn't, if you just get Clang, it's all in there. You don't get that on a Mac. They're a bit behind, and in other things, they're just doing things a bit differently. And yeah, we just kind of need to keep that in mind all the time, and that can be a bit frustrating sometimes.

I guess they have reasons why they need to maintain that fork. And it does seem that someone has started keeping track of Apple Clang features on CBP reference if you look at the feature table. So that's at least something. Oh, yeah, I wasn't aware of that.

Yeah, I need to look at that table again. That's actually really useful. Thank you. I think that was only just added in the last couple of weeks because I swear it wasn't there last time I looked and I went to ask someone to add it

and it was there. And I'm like, I don't think that I'm crazy, but anything's possible. I wanted to go back to, you said you spent one day in the Oogie group, evolution working group incubator. We did have Vittorio Romeo on, I think two or three months ago, talking about his epochs paper. How did the committee take to his proposals? So it was only seen by the incubator group, which is not the committee take to his proposals so it was only seen by the incubator group which is not the committee it's like a particular group of people who talk basically talk about like the newest proposals that are coming in and kind of vetting them before they go to like the evolution

group um so i think um a lot of people like the idea i think um i think the community also likes the idea from what i've seen so far. There's quite a few problems with it. Like there is worries that we're going to end up in this kind of maintenance hell where, you know, when we like make a new feature, then we need to worry that we need to make sure that it doesn't break like C++ 17 and C++ 14. And now we have to that kind of, we get like another dimension on that axis. So like then we need to also worry about not about what epochs do we want to support. And there's ways around that. You can say with the newest feature, you only support the latest epoch or whatever. But yeah, it's not obvious how to deal with that.

And I don't think it's going to be the committee is... Let me put it that way. I think it's going to be a committee is... Let me put it that way. I think it's going to be a controversial discussion when it goes to evolution. I don't think it's straightforward. On the one hand, yes, we have a lot of old baggage in the language which everyone wants to get rid of. But on the other hand, we need to stay back what's compatible

and the committee is already overworked. How do we keep on track and how do epochs fit in? And I don't know the answer to these questions. So I think it's going to be an interesting discussion. And you say you presented some of your own papers to Oogie? Yeah, yeah. I just had like a couple of small papers.

So kind of my thing is, so I'm obviously interested in audio. So yeah, I propose about that, which is a bit bigger, but most of the stuff that I do, I'm not one of the kind of smart guys to come up with like the big important features so what I do is is like little little things that kind of help clarify things or help fix things or make things more consistent or like just little performance improvements that we that you know low latency people need or other people need like so I had

a paper about assumptions, portable assumptions, which kind of came out of the collapse of contracts because you know how you can, like on some compilers, you can say like built and assume and then some expression and then the compiler is going to optimize based on that assumption. Okay. And then basically that was proposed. Then people said, no, contracts are going to do that.

Then it was proposed again and then people said, no, contracts are going to do that. Then it was proposed again, and then people said no, contracts are going to do that. Now contracts are kind of, okay, that's another story, but contracts are not going to happen soon. So now I went off and said, okay, now actually I'm going to think this through and try to make this feature work on its own. So just have a way to express

assumptions and inject them into the compiler. And I had a paper about that, which was well received. So I think it's going to go to evolution next time, and we're. And I had a paper about that, which was well-received. So I think it's going to go to Evolution next time, and we're going to have a wider discussion about that. So that's going to be interesting. I had another one where, you know how some types, they have the same structure as arrays?

Like with std-complex, for example, there is this weird thing in the language that you can cast it to an array, actually, and pass it to a C API or something. But then for all other types, it's a weird exception. It's just for std complex. And for all other types that have the same shape, it's like UB. You can't

do that. You can't just reinterpret cast it to something else. But then people do that all the time anyway. Like, in audio, we have, like, SIMD packs, which, you know, we cast to floats or whatever. And then even in Qt, there's like a Qt color, the class Qt color, which is used all over the place. It's like a union of like a struct with five ints

and like an array of five ints. And that's all UB, but people are using it all the time. So I'm just trying to kind of clear up the object model in such a way that all this code that people are already using is actually fine. And we define what that means. And it's doing the right thing. And there was another paper which is also in that space which I am not the author of.

Christian Stasiovski is the name of the author, but he was not there, so I was kind of championing his paper. Which was another one of those fixes where, did you know that... Oh, let me ask you a question. This is a nice quiz question. How do you print the bytes of an object? Let's say you have an int, which has like four bytes. How do you print those bytes? How do you implement a hex editor?

Well, you are allowed to observe that int as a character pointer. Yes. Explicitly allowed. Then I would dump that straight to standard, to libformats feature for dumping an array of bytes, and it would print it out for me. Well, not quite, because the standard doesn't say that chart points to bytes.

It says it still points to original object. What does it mean? It doesn't really mean anything. And because there is no array, you can't even loop through the bytes because you are doing pointer arithmetic on something that isn't a range. So that's all just UB and that's completely broken and there's this

paper which attempts to fix this. But it is explicitly allowed. It is explicitly allowed to memcopy the bytes in and out of an object that is trivially copyable. You can memcopy it.

That's true. Yeah. No, no, but it says as if with memcopy. It doesn't say memcopy is required. So you can do it with memcopy. You can't. Yeah. If you call one of the other C functions, then yeah.

But you can't just access the array. Because it's not an array. Because it's not an array. Because it's not an array. But people are doing it all the time, right? So this is just, we just need to fix that. And there's like all these like fixes in the object model. So there were two that we got in that other people did, so which are kind of in the same space.

So we got std bitcast from JF, which is one, which is really important. And we got, oh, that's that's something that happened in belfast so the other paper in that space is richard's paper about um uh what's it called p0593 um basically um that you can um objects kind of materialize um if you have like an array you cast it an object and that object kind of springs to life uh-huh And you might get that paper into 20 actually kind of as a last minute job. Really? So then you can actually do, you can memcopy, you can, what's it called? Malloc.

You can malloc a buffer and then cast it to, reach up and cast it to like a widget and then it's going to just be a widget. So that's also not going to be a B anymore. You don't have to do a placement new there or anything. Yeah, yeah, yeah, exactly. So that's also not going to be a B2B anymore. You don't have to do a placement new there or anything. Yeah, yeah, yeah, exactly. So that's another one of those fixes. There's like a bunch of papers in this space. Some of them are in 20, some of them are going to be

hopefully in 23, and I'm kind of working on some of those and trying to kind of clean it all up. That's a huge change if that gets into, or a huge steal if that gets into 20, I think. Well, that changes a lot of things that I teach. Richard's paper, yeah, I think Richard's paper is really changes a lot of things that I teach. Richard's paper. Yeah. I think Richard's paper is really important.

And I'm happy that we might get it in. Yeah. Not the, not the library part. So he had like a thing where you can explicitly do that. It's now called start lifetime as, which is basically the drop-in replacement for the interpret cast that you would do before. Right. So we didn't get the library part in, but we might get the language part in,

which is going to just un-UB a lot of code. Wow. Yeah, check it out. It's P0593. I think it's a really, really good paper. The paper is Implicit Creation of Objects for Low-Level Object Manipulation. I'll make sure to put a link to this one in the show notes.

I got a brief chat with Lisa about that, too. Weird, scary, low-level object model stuff. And I think most people shouldn yeah it's kind of chat with lisa about that too weird scary low level object model stuff and i think most people shouldn't even be kind of aware of that and they should just you know do do the code that works but under the hood it's like really important cleanup stuff that's going on there so okay i wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high quality code, as well as the methodology of static code analysis. In their blog, you'll find many articles on programming, code security, checks of open source projects, and much more. For example, they've recently posted an article

which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly use static code analysis. Speaking of which, another recent article shows how to set up regular runs of the PVS Studio static code analyzer on Travis CI. Links to these publications are in the show notes for this episode. Try PVS Studio. The tool will help you find bugs and potential vulnerabilities in the code of programs written in C, C++, C Sharp, and Java. You've mentioned your interest in audio

a couple times. Did you attend the SG13 meeting, which is the Human-Machine Interface Study Group? Yeah, I spent a day there. So yeah, that's really exciting. So obviously that's my main interest because that's the industry I work in. It's like pro audio. So, yeah, so we had a paper on graphics, which is basically just another update of the existing graphics paper where we just had a few updates.

You know, people had comments. They responded to the comments, like a little API update. We had a paper about WebView, and then there was no update of my audio paper this time. So I have this proposal together with Guy Somburg and Guy Davidson to actually standardize an audio API, which is kind of on the list of things that the direction group said, like we need all the stuff in the library.

So it's like networking and graphics and audio. So we're trying to come up with a standard audio API. We've been working on that for quite some time now. So this time we didn't have an update on our paper, but we had another paper from Frank Birbacher about audio where he looked at our proposal and said, you know what, here's a few use cases that I don't think are covered by your current proposal.

And, and that was, we had quite a long chat about that in SG 13. I think it was really interesting because I think we focused on, you know, low level C++ kind of audio API where like the motto is, you know, C++ is good at abstracting away from, from like hardware with low overhead and, you know, you should be low level and just

get like the minimum kind of like stuff to just basically push audio data to your sound card, right? But then that basically talks to the sound card. But then in a lot of devices, you don't get access to the device directly, like on a phone, for example. You don't get to choose like, oh, I want this device, I want that device, I want this sample rate or whatever.

So the operating system just does that all for you. So it's like higher levels. So you just get to say, my app wants to output some audio. Here's like some audio data. And then the operating system kind of decides what happens with it. And then if you get like a call, then it kind of fades out automatically and this kind of stuff. And in our API, you would have to do all that kind of yourself and it's like on a phone that's not

really how it works right so it's like it's kind of low level versus high level approach um and yeah it's kind of unclear um you know obviously i'm familiar with the low level stuff but you know a lot of other people are not and it's unclear what the right level is to go to the standard so i think with our proposal we will definitely proceed i think to try to get it into boost um like boost audio um but um yeah but the the standard stuff i think we're gonna first have to have a chat about like what the right level is like what the and we're doing now the same that we are doing with contracts which is you know contracts got pulled last time. So now, again, it's like unclear because there's too many people

who want different things from this thing. So the same thing is happening with audio now where the approach is, okay, you know what? Let's just look at the use cases. You know, what do you want to use this feature for? You know, it should be doing this and this and this and this and these users need this for that and these users need this for that.

And then kind of get consensus on which of these use cases for which of these users we want for that. And then kind of get consensus on which of these use cases for which of these users we want to support in the standard library in the audio case or like for contracts like in the language. And then try to get consensus on that first and then go back to

the actual design of the feature with hopefully this debate then being kind of out of the way mostly. And I think that's a great approach. We're starting to do this more and more, just to focus on use cases on the committee. And I think that's a great approach. I really like that.

That's a good way to get out of different opinions colliding and different people want different things from the same feature. Wow, makes sense. It sounds, yeah, I mean, the graphics proposal ran into a lot of the same problems, it sounds like, too, right? Yeah, they haven't started that process for graphics yet. I think they should maybe do that. But then also their API is, like, really mature.

So I'm not sure how to approach this. They have wording and everything. It's basically almost, it's ready to go, basically, right? Right. So it's kind of stuck in the wheels of the committee because some people just don't think that this should be the right level. Yeah, I don't know where this is going. I'm following the progress, but I'm hoping it's going to go somewhere

because personally I think all the stuff belongs in the standard library, right? If you have a high-level programming language, you get a laptop, you open up the compiler, you start writing some code, you need to be able to, like, draw a pixel on the screen, right? What's, like, the most elementary way, you know, a human interacts with software is basically you look at a screen,

so you need to be able to draw something there. That's number one. Number two is you need to be able to receive input, like mouse and keyboard or, like, touch or whatever. So you need input. And number three is audio, right? Because without that feedback, imagine a game without audio or any app without audio feedback.

So I think these three things are the fundamentals of human-machine interaction. And if we have none of them in the language, we only have the terminal, basically, as the output, right? And the file system. But then on the phone, you don't even have a terminal. So you can't literally write anything in C++ that runs on the phone without using non-standard kind of third-party stuff right and i i don't

think that's right so this is kind of i think kind of the overarching kind of theme here but people disagree so you know fair enough let's talk about it and that's been going on for a while now are there any existing uh cross-platform audio libraries that you're referencing when working on the audio proposal? Sure. There is quite a few. I mean, we've been doing this like 20 years in the audio industry, right? So there's like Port Audio,

there's Juice, there's quite a bunch of these kind of cross-platform APIs that are really mature. And what we're really trying to do is we're going to take like these APIs, which actually look kind of similar, like if it comes to like just the I.O. and the audio data,

and just make them a bit more modern C++, and then do that. But then there is another problem, because now people who are not necessarily familiar with audio but are familiar with other kind of asynchronous-ish things, like networking, they come to us and say, hey, this is not how you should be doing callbacks. We now have senders and receivers and executors and core teams,

which, by the way, is really exciting, and they're right. This is a great way forward for asynchronous stuff. And I'm really excited about what Eric Niebler and Lewis Baker and Kirk Shoup and a lot of other people are doing with the sender and receiver stuff. Actually, quick interruption. Executives, they now actually agree on an executor's design

that they can actually explain to other people that actually makes sense. That's another first. So that's a great thing for us. So that's all the stuff going on, but we seem to be able to agree on a model how to actually do asynchronous stuff and callbacks in modern C++. But then they tell us,

well, this is what you need to do in audio, but this is not what we have been doing for the last 20 years. If you take this stuff and take this to audio developers, that's going to be not an API that they're familiar with. So that's not really going to be

standardizing existing practice. So I'm not sure that's the way... I mean, it just sounds weird to me. Like you said, you have 20-some-odd years not really going to be like standardizing existing practice so i'm not sure that's the way i mean it just sounds weird to me like like you said you have 20 some odd years of existing best practices but networking is is asynchronous audio is asynchronous but i see a fundamental difference networking is never real time audio that's basically always real time right yeah so networking um yeah there's like things like in networking um you know you can throw and then you have like a nice mechanism how you can kind of capture that exception and like get it in the other thread like in audio you can't throw

right you have a callback and you have like a millisecond or like less to like fill a buffer with a bunch of numbers and and And if you fail to do that, then there's going to be garbage numbers in the buffer and they're going to go to the speaker. You're going to actually hear that, right? So then your app is not going to work because you're going to get clicks and noise. So I think it's different.

But the idea of a callback is the same. So there is some overlap. But how this callback is actually implemented under the hood is quite same. So there is some overlap. But like how this callback is actually implemented under the hood is quite different. And the way you write code is quite different. Because audio is essentially real time. So when you're in this processing callback, you can't lock a mutex,

you can't allocate memory, you can't do anything that takes an unbounded amount of time, basically. So you need to be really careful about how you write code. And this is why we use C++, because C++ is, you know, you need to be really careful about how you write code. And this is why we use C++, because C++ is, you know, you can express things like that in C++. And humans are, we're incredibly sensitive to this. If you get more than a

10 millisecond delay or something, people start to notice, right? That's the fascinating thing about audio. So, like, you know, in games, like, I mean, on the face of it, it's the same thing. Like, games is like 2D instead of 1D, and their frame rate is lower, but then the data rate is higher, basically. But there's one difference where if you have 60 frames per second,

we have like 44,000 or 48,000 samples per second. So that's a lot more. But then also if they have 60 fps in one frame they drop one frame no one's really gonna notice right no but like if you have an audio signal which you sample with like numbers like 48 000 times a second and and like one of them is missing and you have a little dip in there you're going to instantly hear that right yeah and so that's yeah that's a very different challenge it's's a very, very interesting field to work in, actually. I wanted to just go back to something you mentioned there. The concurrency and parallelism study group says that they have agreed on their unified executors proposal for C++.

So there are like a number of things kind of waiting on executors to be approved. Does that mean, you know, we think we should get executors into C++23 now that they're all in agreement on this proposal? Yeah, so I mentioned this briefly earlier. So we had an evening session about that where they were like, here's what we think the design is. And they spent years on this, right?

So lots of people put a lot of work on this. And finally, they have a design where they had unanimous agreement in that study group that this is the design you want to go forward with for cpss 23 i think that's the first time this happened they had like unanimous agreement yep we're fine with that so now it's going forward um and yeah so i think now everything that depends on that is pretty much unblocked so great um yeah that's really good news that's yeah that's the other exciting thing that happened at

belfast so it's not really for 20 which is why i didn't mention it in the beginning but right yeah i'm really really excited about that and like i'm struggling to get my head around all this new stuff but so i sat down with some of the people who work there and they kind of just talked me through it like in a pub in belfast over a beer and i was like oh yeah yeah this actually makes sense you know it's like sender and receiver stuff and um it's it's super fascinating so um i still i don't claim that i actually understand it yet but um it starts to make sense slowly so i definitely recommend you check it out um i think it's really exciting stuff i was going to ask if it still made sense after the beer wore off um That was just last week.

I haven't looked at it since. So as far as things that were actually accepted into 20 changes here, there's one thing that I have not been able to wrap my mind around. And I tried to read the paper on it and made global initializers ordered between translation units when at least one of them is in a header unit or module interface. Now it sounds at the surface that this is like dealing with the static initialization order fiasco but i feel like it can't really be okay um so first of all so the static initialization fiasco is the constant

paper um which we have that's done that's um the paper's done. But that doesn't change anything. You have to use the new feature to... Yes. So the paper you're talking about, I was not in a room for that. P1874R1? Although I can't actually... Yeah, yeah. Initialization order of non-local variables.

Yeah, okay. Yeah, yeah. So I wasn't in a room where that was discussed, so I can't really say anything about this paper. Maybe I should check it out, yeah. Start.dynamic, basic.start.dynamic is where things get changed. So maybe, yeah, people should read this and figure it out. So the thing about the committee is that there's so much going on,

and a lot of it is just way over my head. It's like modules specifically is something that I haven't been following in much detail. There's like all these streams of incredibly complicated things and the survival strategy is basically you focus on those that you understand and your users care about, which is a bit. And then you have like a working understanding of some of it, and then some of it you just have to say, okay, I'm not getting into this now.

Because otherwise it's just too much, you know. This is, like, this has to be kind of your survival strategy if you want to be productive on the committee. Because, like, so much stuff going on. I think we have now something like 12 groups sitting, like, in parallel talking about stuff. So, yeah, it's actually quite overwhelming so yeah this is why i'm not familiar with that particular paper yeah that's fine i didn't know

if you would be and then but on that note of all the different groups that exist there's a re-chairing of all the groups which i find interesting and then also a new working group or study group on abi issues I saw that somewhere in here. Yeah. Yeah. I should just make a show note that we're going to be talking to Titus Winters next week. So I figure we'll probably be talking a lot about the ABI stuff there, but you want to just quickly talk about what you know about this new ABI group? Yeah. So it started, like I became aware of this when I think

Titus wrote an email on the committee mailing list a couple months ago starting this. Twitter, yeah. Yeah, so then it kind of became public about like what do we actually want to do? You know, we're claiming that we want to be performant, but then we have because we don't want to break

ABI, we have all the stuff which actually isn't performant and we are keeping it that way. For example, UniquePointer. A lot of people think that UniquePointer has no runtime overhead, but actually it does because it has a non-trivial destructor, which means you can't pass it in a register, which means that's an ABI thing,

which means it's going to have some performance overhead. And we could change the rules and make it have no overhead but that would be a breaking abi change which means not an api change but an abi change right so if you have a pre-compiled library you wouldn't be able to link with that anymore you would have to recompile that and yeah that's a problem in audio as well like we have for example some people who come up with like really clever really cool algorithms for like you know like pitch shifting or whatever. And they don't distribute the code.

They just distribute the binary. And we need to just link against that library forever. So we're at their mercy to recompile it. And so this is why ABI stability is really important. So he's saying, okay, are we now actually prioritizing ABI stability?

Or are we prioritizing performance? Because these are clearly at odds with each other and the committee has never said which one you prioritize. So he was kind of trying to force this discussion. And yeah, now so we're going to have a whole bunch of smart people. I think David Van der Voorde, I think, is chairing this

group. He's one of the experts. And yeah, they're going to spend time talking about it and and figuring it out and maybe there are things that can be done to kind of make both camps happy so yeah i think it's it's important it's an important discussion that needs to happen so i'm really looking forward to what titus is going to say about this on your next show i'm sure it'll be an interesting one yeah the other thing i'd like to go back to if you don't mind is a proposal that you said that you submitted for,

and I'm sorry, I can't remember the wording, but for saying assumptions, like that the compiler's allowed to assume this value is never less than 5 or whatever. Yeah, yeah, yeah. I was just curious, what syntax did you propose for that? If it's going to be attribute syntax, like the contracts were supposed to be, or what? I'm glad you asked.

So the current what's published is P1774. I was kind of like, we have various options. We discussed this and now I'm going for the attribute syntax. It sounds appropriate on the surface. Not the one that contracts had with the colon because the colon makes it not backwards compatible, because you can't have a colon in an attribute. So I'm proposing a proper attribute syntax.

We have square brackets, square brackets, assume, paren expression, paren, square brackets, square brackets. And that's actually backwards compatible. So then old compilers at least can ignore it. The other option that was discussed was std assume, which would be nice because it would be consistent with std assume align, which is another proposal that I actually got into 20. So these are all basically standardizations of intrinsics that already exist

and people already use. But anyway, std assume doesn't quite work because it's essentially like a keyword. It's like deco type or something like that. It's like an unevaluated context. So the thing in parens is not actually being executed ever. So the compiler is going to look into that. So if you say assume x greater than zero,

the compiler is not going to actually evaluate x greater than zero like in your code. The compiler is going to analyze it and say, well, okay, so, you know, I might evaluate, I would be able to evaluate this maybe. And then if I were to do that, and that would return false, then it would mean this and this. So I can assume that this is just not going to happen and optimize the whole program on that assumption. But that stuff is never actually evaluated, which is why function called syntax just doesn't work and which is why we can't really have this instead because then you would have something like a namespaced operator essentially

or like a namespaced macro keyword kind of thing and that's, yeah, we can't really do that we briefly talked about this and it's just not going to work I think the attribute syntax is a lot cleaner, a lot better I wonder how much assuming that gets accepted how much that

might influence the future design of contracts as well so we also talked about contracts last week um but obviously now we're in the stage where it was kind of like a post post-mortem session in a way right right where like now we are just looking at the use cases and a bunch of people are going to write papers like you know which use cases are already supported in the language and which proposals did cover which use cases. How do we go forward? But not concrete new proposals yet. So what they're going to do, I think,

I think assume is useful. It's a very kind of sharp knife. It's a very low-level expert kind of feature. But it's useful as a hook into the compiler to inject information to the compiler. And feature but it's useful as a hook into the compiler to inject information to the compiler and i think it's useful as a standalone feature for like very kind of low level stuff um and then if the contracts people um if they then say hey you know we found a way to integrate this with the contracts facility um and here's like a unified proposal then i would be totally happy with that. That would be a good outcome.

But what I don't want to happen is this thing that happened already twice, which is they said, oh, yeah, don't do that because contracts are going to do it, and then they actually don't end up having contracts that can do that. Right. Right. And so we then get neither of these things, and that's not good. And quite a few people are saying now that assumptions and assertions are actually different things, like even conceptually the way you think about this, right?

So one thing is like, you know, here's the thing I want to check and maybe act on that check or maybe not check. So here's like a statement about, you know, if this is false and my my program has a bug please do something about that and this is i think what contracts are all about but then assumptions are very different assumptions are i know this is true because some other invariants somewhere else in my code are enforcing that that's like just my how my code works i know this is true and the compiler maybe would be able to even optimize on that but it just can't see that bit of information because maybe it's a different translation unit or maybe the code is too complex.

I'm just going to help the compiler out with telling the compiler, hey, this is definitely true. Please optimize based on that. And I think assumptions and assertions are two very, very different things. This is how I think about that. Right. Okay.

So we've talked about the Oogie, EWG groups that you attended some of their meetings. You went to SG13, talked about audio and graphics. Is there any other study group where you spent a decent amount of time that you wanted to talk about any progress they made? Not really anything I was kind of deeply involved in. I think the rest was maybe the hallway track, you know, where you go to lunch with people, you go to dinner with people, you go to the pub. Like Belfast has amazing pubs,

and the Guinness tastes a lot better than anywhere else. So you go there, and then you keep talking about this stuff, and this is where you create ideas. So now, you know, I came back with like a few ideas. Like, oh, maybe, you know, we could write a proposal that does this or whatever. So that's like the other stuff that's always happening at these meetings, which is really exciting. But yeah, I think now I'm looking forward to Prague. That's the last meeting where we can fix things.

And then at the end of Prague, we're going to be done with C++20, right? Right. So that's going to be a huge thing it's going to be definitely a reason to celebrate and yeah so I'm really looking forward to that and getting all these features Just going back to the National Body comments for one moment, did you address like half of them or

address all the ones that have come in so far and now the National Bodies have one more chance to write new ones? How does that work exactly? So they only had one round of writing them, so that's kind of done. So now they just get to vote yes or no on the whole standard. But we didn't address all of them. So this is why we have two meetings because there's a lot of them.

It's literally hundreds. So I think we did about three quarters of them. Okay. And, yeah, I think Herb actually wrote a report. I think he has like a pie chart. hundreds so i think we did about three quarters of them okay and um yeah i think herb actually wrote a report i think he has like a pie chart um yeah so so i think we looked at about three quarters of them about half of those or even more we kind of rejected as like that's not a defect or that's a redesign you can't do that at this stage and then the rest was fixed addressed um resolved um yeah and then we still have i don't know something like i don't know 70 80 or 90 or something like that comments

to process in belfast i don't know the exact number but sorry in prague yeah um i don't know the exact number so we did about three quarters and we got another we get another round in prague for that and then and then we're done. Yeah. Since you just mentioned the Prague Standards Committee meeting coming up, I feel like I should give a quick shout out to the Prague C++ Meetup. We started the conversation with the discussion about the new meetup in Maryland. I'm going to be speaking at the Prague meetup in two weeks. And then in December, Chandler, Kruth, and you will be speaking. And then in December, Chandler, Kruth, and you will be speaking. And then in February, we've got, or they've got, Tony, Van Eerd, Bjarne, and Herb speaking during the course of this committee meeting.

Yeah, shout out to Hannah Dushikova for organizing an amazing user group. So I don't know how she gets all these amazing speakers, but... With the support of an amazing company, I would assume, because otherwise... Yeah. So yeah, definitely looking forward to that. And since you mentioned Hannah...

I was just going to say, since you mentioned Hannah, she is one of the people who is now a chair of one of these groups. She's going to be the chair of the reflection group, right? Yeah. She took over from Chandler actually.

They're doing lots of very interesting work there as well. She took over as the chair. Yeah, that's good news. Okay, Jason, is there anything else you wanted to go over? No, I'm good. Timur, it was great having you on the show today.

Thanks for telling us about all the belfast news thank you very much for having me it was a pleasure good luck with uh meeting c++ yeah yeah three more days of c++ madness and then i can finally go home and relax a little bit okay all right thank you thank you very much for having me thanks thank you thanks so much for listening in as we chat about c++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic,

we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support Thank you.