CppCast - mdspan and /r/cpp

Episode Date: August 15, 2019

Rob and Jason are joined by Bryce Adelstein Lelbach from NVIDIA. They discuss the mdspan proposal that first introduced Bryce to the C++ ISO committee. They also review Bryce's role as moderator for the /r/cpp subreddit and talk about the upcoming CppCon 2019 conference. News Resharper 2019.2 released Game Performance Improvements in Visual Studio 2019 16.2 The German Center for Aerospace (DLR) just open sourced CosmoScout VR, which is a universe 'simulator' written in modern C++ Links P0009r9: mdspan: A Non-Owning Multidimensional Array Reference P1684r0: mdarray: An Owning Multidimensional Array Analog of mdspan P1767r0: Packaging C++ Modules /r/cpp/ CppCon 2019 CppCon 2018: Bryce Adelstein Lelbach "The C++ Execution Model" Sponsors Backtrace Announcing Visual Studio Extension - Integrated Crash Reporting in 5 Minutes

Thank you. Windows, mobile, and gaming platforms. Check out their new Visual Studio extension for C++ and claim your free trial at backtrace.io. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Come join us in Aurora, Colorado, September 15th to 20th. In this episode, we discuss updates to ReSharper++ and Visual Studio. Then we talk to Bryce Adelstein-Lolbach from NVIDIA. Bryce talks to us about the MD spam proposal and much more. Welcome to episode 210 of CBPCast, the first podcast for C++ developers by C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I'm alright, Rob. How are you doing? I'm doing okay, aside from fighting with the CppCast website all week. Ah, yes. So if you're following along on Twitter, the website went boom. Yes. It died spectacularly.

Although if you go and navigate to it, it's still there. It's just out of date by a week and a half. It still shows recent episode with claire mccray about approval tests does not show matt butler's episode uh insecure coding yet but hopefully i'm going to fix that this week and by the time you're listening to this the new website will be up that'd be great yeah and i and the next i just realized within the next month, am speaking and giving four talks at two conferences and teaching three classes. That's very busy, Jason. That's a busy month, yes. Yeah.

I'm looking forward to October, basically. Yeah, I would be too. Okay, well, if Todd Ferris would like to be a piece of feedback. And yeah, if you're following on Twitter, you saw that I put out a request for suggestions for a good alternative static site generator. We were previously using DocPad, which was a JavaScript-based static site generator that is apparently horribly out of date.

The maintainer of it says it hasn't been supported for like three years. So we got a couple recommendations for hugo as well as some other uh generators and i'm going with hugo because we had corntin jabot uh you know recommended it we had ron recently as well as a couple of people on twitter i like this one recommendation of wikipedia yeah i i don't think that's gonna work although i mean the wikipedia the wiki what is it that's gonna work although i mean the wikipedia the wiki what is it called like it's still i assume it's still an open source backend anyone

can just make a wiki it would be it would be an idea but no no yeah so we're going with hugo and hopefully i'll have that new site with hugo up this week looking forward to it yeah 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 cpcast.com. And don't forget to leave us a review on iTunes and subscribe on YouTube. Joining us today is Bryce Adelstein-Lelbach. Bryce has spent nearly a decade developing libraries in C++. Bryce is passionate about C++ evolution and is one of the leaders of the C++ community. He's an officer of ISO, IEC, JTC1, SC22, WGD21, the C++ Starens Committee.

Bryce chairs both the C++ Committee's Tooling Study Group and Library Evolution Incubator. He is the Program Chair for the C++ Now and CppCon conferences and the Chief Organizer of the Bay Area C++ User Group. On the C++ Committee, he has personally worked on the C++17 parallel algorithms, executors, futures, senders, receivers, multidimensional arrays, and modules. Bryce works at NVIDIA, where he leads the CUDA C++ core libraries team. He's one of the initial developers of the HPX parallel runtime system, and he's also helped start the LLVM Linux initiative and has occasionally contributed to the Boost C++ libraries.

Bryce, welcome back to the show. It's good to be here. That's quite a mouthful. Yeah, your bio has gotten longer since we last had you on. As Rob's reading along, I'm like, does he actually work anywhere right now? You know, it's funny. People seem to ask me that a lot because I think I've spent about half of this year in the office and about half of this year at conferences or committee meetings. And your employer expects this?

Yes, my employer expects this. Yeah. Okay. They care about what we get done, not necessarily when we're there but uh the for for nvidia um uh supporting the c++ language is is very important it's a it's a bigger picture like strategic goal for us so we really care about the c++ community and that's why we have so many people from nvidia that go to c++ committee meetings um and. And we actually, I think we're the only organization that has people chairing three different groups

of the standards, subgroups of the standard committee. Like Google, Microsoft, they get a lot of the press for having involvement in the committee, but it's great to hear that NVIDIA invests that much in it as well. Yeah. Okay, well, Bryce, we got a couple news articles to discuss. Feel free to comment on any of these, but it's great to hear that NVIDIA invests that much in it as well. Yeah. Okay. Well, Bryce, we've got a couple of news articles to discuss.

Feel free to comment on any of these, and then we'll start talking more about your recent work with the committee. All righty. Okay. So this first one, we have an update from ReSharper C++ from JetBrains, and this one is 2019.2, faster indexing, improved C++20 support, and better Unreal Engine support. And yeah, I mean, it's always great to see them keeping up with the standard

and improving ReSharper C++. I'm definitely a user, so I'm looking forward to grabbing this new update. Yeah, it's interesting timing for me, because I was doing some research for one of my talks, and I installed ReSharper just to help with some refactactoring tools and stuff. It's the first time I installed it in a couple of years and I'm getting these, you know, pop-ups from, uh, from Visual Studio. ReSharper's plugin has taken six seconds of unresponsiveness and it's a large complicated project. Uh, so I'm like, oh, well look look a new release was out literally like five days

after i installed the one that i had and to see it's got you know performance improvements that seems immediately welcome yeah i think visual studio will will let you know about any plugin that's being a little slow but it's you know yeah i never really noticed it yeah yeah it's pretty exciting because they um they've asked already started adding support for c++ 20 features yeah in this release including features that were like just just added to the standard the last meeting yeah so the new char 8t type is in uh conditional explicit yeah plenty of new c++ 20 features yeah yeah, const about, const note. Yeah. And I was just, you know, it's not directly related.

I mean, they did a bunch of code analysis updates as well, and I was impressed the last time I installed it just how much the code analysis kinds of things that it does, where it's telling you this variable should be const or whatever. So it's always, I mean, everyone knows I'm a huge fan of tools. It's great to see even more things coming, improvements. Yeah. I mean, speaking of performance, I think down the road, tools like ReSharper will really be able to benefit from modules.

It's just potentially quite a big task for them to integrate modules into their tool. I mean, it's a very different way of browsing through your source code, but modules should allow them to only load the entities that they need from a particular translation unit instead of having to parse through everything. So it's a very exciting future for tools in our new modular world. I'm kind of curious if our compiler vendors do a good job of publishing their module specs, how much that'll help tool vendors, too, if they can just directly parse the module output. Well, one of the reasons why we are creating this C++ modules ecosystem technical report out of the tooling study group is to give the implementers a place where they can come together and agree upon things

and give tooling vendors a resource that they can use to figure out how to integrate with modules and with particular implementations of modules. Okay. This next one we have is from the Visual C++ blog, and this is Game Performance Improvements in Visual Studio 2019 16.2. And they're going over a bunch of optimizations and actually showing some assembly output and some of the changes they're putting in. This first one showing vectorizing tiny perfect reduction loops.

And then they're showing how it goes to a fairly large block of assembly down to just five lines of assembly. So definitely showing some good performance improvements here. Also looks like they're doing some better job of constant folding, which I'm always a huge fan of. If the compiler can just make the code go away altogether, that's better. Can we all agree that the first example should probably be replaced with a std reduce or a std transform reduce? And that's the real optimization we want here. Gotta Sean parentify that code. That is a good point. I didn't see it immediately. I tried to be familiar with the algorithms, but there's a lot of them. Yes, there are a lot of them, yes.

There is one other thing that stood out to me on this, and it's been kind of itching in the back of my brain here. It's ARK AVX2. That's great. Slash O2. That is all optimizations in Visual Studio. That's great. And then FP colon fast. Wait a minute, floating point fast math. I'm pretty sure I've heard clang developers say that should never be used because do you want accurate results or not is the the answer there? Is that also true in Visual Studio? Or am I overthinking this? Well, that's sort of a matter of a matter of opinion. I mean, a lot of people in the scientific computing world will use fast math,

but then there's a lot of people in the scientific computing world who won't use fast math because the loss of accuracy guarantees is not acceptable for them. But I think it really just depends on what you're optimizing for. Are you willing to sacrifice some fidelity for speed. Yeah. And if this post is about visuals or about game performance, then I could definitely see them going with fast math. Yeah.

Yeah. Yeah. I actually had a class of a largely physicist in my last class and I was having some brief discussion with them. How some game developers describe game programming as like physics simulations, but at real time. Yeah. They throw away however much accuracy they can

to get something that looks good. Yeah, but of course, if you're simulating something that is going to be mission critical and you want to make sure that it's accurate, 100% accurate, that's a very different type of physics simulation than a game where you just need it to to look good enough right and then this last article we have is about cosmos scout vr

jason you want to tell us more about this one yeah i mean it got a lot of uh well basically attention on on reddit here so i thought it was worth mentioning, but the German center for, um, what is it? Something? Yes. German aerospace center. There we go. Uh,

has released their like VR tool for, for browsing through our planetary bodies and doing simulations of planetary bodies, celestial bodies and stuff. And it's open source and at least relatively modern C plus plus. And it looked interesting. I don't personally have any way of viewing vr things no i i do not either and i'm wondering is it vr required like can you

could you just run this on your desktop or laptop without having any vr equipment or is it really require vr hey no it says interaction works both in vr on desktop, so you could try that VR. Do you have a, since you work for NVIDIA, have a room full of VR gear, Bryce? I have a lot of VR-capable GPUs at my desk. I have somewhere in the range of 20 GPUs at my desk. I don't actually have any VR equipment, but there's a bunch of people who sit in the general region that i that i'm in that have all sorts of cool vr uh stuff so you're

like at your desk at work and you're like oh someone comes by do you have an extra you know whatever high-end video card and you're like well i think i've got a spare one around here somewhere and you just like i'm very organized about it each one of them is labeled in three places um and uh has my name on it and there's a sign-up sheet because otherwise stuff never comes back that's just easy to believe it's like loaning a neighbor your tools exactly exactly very cool okay well bryce um we actually got this email from a listener recently asking us to have someone on to talk about MD-SPAN, which is a proposal to add a, what is it, a multidimensional array to C++. And I saw that you were one of the authors on this paper. So could you start off by maybe just telling us a little bit about what MD-SPAN is?

In fact, MD-SPAN is the first paper I was ever involved in on the committee and in some ways was why I joined the committee. So MD-SPAN is a multi-dimensional version of SPAN. So if you know what SPAN or StringView is, then you have an idea of what the basic properties of MD-SPAN is. That is, it is a non-owning reference or view type. So string view is a non-owning view type that cannot modify its underlying elements. That's not what MD-SPAN is. MD-SPAN is more like SPAN, where it's some view into some type of container

and it can modify the underlying elements. Conceptually, you can think of it as, like if you think of span conceptually as being a pointer plus a size, then MD-SPAN is conceptually a pointer plus a set of sizes or what we call a layout, some way of indexing into some contiguous or potentially non-contiguous range of storage. So one of the key design goals of MD-SPAN was to give us a type that parameterized the layout. So, for example, if you were switching from column major to row major layout, you would

not need to change how your code that uses an MD-SPAN is written. You would just change the layout parameter of MD-SPAN. Whereas if you're writing just a raw indexing code for row major versus column major, you have to go and change all of your loops if you want to switch between different layouts. So one of the goals here is to give us a type that we can easily swap out the underlying layout of the multidimensional structure, which sometimes you want to do for performance reasons. Sometimes you want to do for interoperability reasons. And that's sort of another aspect of MD-SPAN is that it's not its own owning container type. It's meant to be something that is an abstraction that references some storage that you, the user, own.

So if you have some matrix type, you can construct an MD-SPAN that points to your matrix type in the same way that you can use string view to create a reference to your own internal in-house string type. So it's something that we've been looking at standardizing for a number of years. It's sort of this very fundamental type for high-performance computing, linear algebra, geometry, 2D graphics. And over the years, there have been an increasing number of people who have looked at this and said, okay, this would be useful for my domain. So I think once we standardize it, it will end up proving to be one of the sort of fundamental vocabulary types of the standard library. So I was just going to say,

so what is the progress on trying to get it standardized? So there was originally an effort to sort of unify span and MD span. So the original span proposal was a multiimensional span proposal, but it was not designed in such a way that was suitable for high-performance computing. And so we eventually ended up deciding in the C++20 timeframe to separate out the one-dimensional type span from the mult-dimensional type because we had a lot more what we call the committee field experience with the one-dimensional span than we had with the multi-dimensional span. So we went from having just one sort of megatype to having span, which has gone into C++20, and MD-SPAN, which I believe is currently targeted to go into the next library fundamentals technical specification right now.

And so because of that, work on it has been a little bit on the back burner for the past year because we've been focusing on C++20 stuff. Now, if you want my opinion, I think it's more likely that we put this into C++ 23 or C++ 26. And if you want even more of my opinion, I'm not a huge fan of the library fundamentals, technical specifications. I just don't think they're focused enough. So I think we'll probably get this in C++ 23, or we'll get it in a TS in the 23 timeframe and then in the standard in 26.

So you mentioned span several times, but I want to be clear, does it require a contiguous layout like span does? No, it does not. It fundamentally has one base pointer though, but the the, the, it might not index into a contiguous region. It might represent a slice of some region.

You can't give it multiple ways. But it's not necessarily the case that all the elements are contiguous within the storage region. So it has one base pointer. Yeah.

I'm sorry, I'm just trying to visualize this so it's like a sub rectangle inside of a larger rectangle not all of those points are contiguous relative to each other but the overall block of memory is contiguous right and you can you can think about even even weirder um layouts like um sparse layouts where the distance between different elements might not even be fixed or predictable. How would that work? The way that you would implement that is pretty simple. You have to have some sort of, like, you have to have more storage for your layout. Typically, your layout storage is just the extents of things, like how large is each one of these dimensions,

how large are my strides, et cetera. If you wanted to have some sort of sparse layout, you probably need more information than that. And also, your indexing operations are probably a bit more expensive. They're not just some simple integer math. But MD-SPAN is designed to be general purpose enough that you could express a more complex layout like that. Or a better example might be something like a triangular layout, which is not necessarily arbitrary, but doesn't a a constant stride between the different elements but but doesn't necessarily require dynamic storage for the position of each one of those elements okay why so why is this uh particular proposal been in process for so long looks like

it was first proposed back in like 2015 it sounds like the scientific community you know has a lot of experience with us why why has it it been in the works for so long? Because it's a big feature. So it's somewhat small in terms of its interface surface, but to get this right, this is a generic interface, and to get this right, we had to put a lot of thought into just what that generic interface looked like. For example, one of the more recent additions to MD-SPAN, the original proposals for MD-SPAN had a variadic set of properties. Properties could be things like, is the memory accessed? Like is it accessed

through a cache bypass? Or is it accessed atomically or other properties like that? And this was intended to be an open set of properties that could be extended by vendors. In more recent revisions of this proposal, we replaced that mechanism because, generally speaking, open extensible property mechanisms in the standard don't have a great track record. So we instead replaced that with an idea of mine, which is this notion of an accessor. So an accessor is an object that abstracts away the accessing of a pointer so if you have an accessor object you give it a pointer and an index and um into that pointer and then the accessor just goes in and like in the simple case just accesses the element at that index um but then having it be an

abstraction means that you can if you want to customize how memory is actually accessed, you can write your own accessor that does whatever weird thing you want and plug it into MD-SPAN. So just like a little detail like that is something that evolved later in this proposal's life, but made it a significantly better proposal because there's as i mentioned at the start there's a ton of different people who want to be able to use this thing so it's really important that we make it extensible enough for everybody to be able to use it okay and one of the comments that i saw come up was there's no great way to make a two-dimensional array in c++ today like do we want an array of arrays vector ofector of vectors is probably a bad idea, that kind of thing. So it sounds like, if I'm hearing you right, maybe I would just create a standard array

and then use an MD-SPAN to say, treat this like a three-dimensional container. Yes, or you could use an MD-ARRAY, which is another proposal that is... MD-ARRAY is essentially a container adapter that is built with an MDSpan and some underlying thing. So MDSpan is sort of this lower-level facility that's this not-only-view type,

but if you just want an array type, we're planning on adding something to the standard that builds on top of this that's a more user-friendly version of this. Planning to. So is that in the same state as MD-SPAN right now, or is it lagging? I believe that paper first showed up at the last meeting.

One of the reasons it was written was because the linear algebra proposals are planning on using MD-SPAM. And so the MD array proposal was written as a part of the linear algebra effort. And I believe that it was seen by Lug, and I'm basing that assumption on the fact that it was an R0 paper that I didn't see in Lugy. So that makes me assume that it was on the Lug agenda, and that's why it wasn't on my agenda. Sorry, you now have to take a moment,

just for listeners who aren't familiar, Lug and Lugie, it just sounds like you're making up words. Lugie is the Library Evolution Working Group Incubator, which is the first, it is a study group that looks at early standard library proposals and gives them feedback and directional guidance before they go on to the primary library evolution group. So typically, and I chair that group, typically that group sees all new proposals that add standard library features before they go to the library evolution group. But sometimes maybe 30 or 40 percent of proposals just go directly to the library, the main library evolution group, just depending on their priority and the amount of time that we have.

So I'm sorry now then, who did you say is currently looking at the MD array? I believe that it was seen by the main library evolution group at Cologne. I don't know what the state of it is. Right. Although that is quick enough, easy enough for one to check. And this is, while you're looking that up, make sure I have my history right,

this linear algebra is the, fork's not the right word, it's a branch of the work that was done in the 2D graphics proposal with our friend Guy Davidson, who's been on a couple times. There are currently two linear algebra proposals. There is that one proposal, which is just what you described, and then there is an industry and HPC-driven proposal,

which I don't have the number for, but it is essentially a proposal for a linear algebra library based on BLAS, which is the basic linear algebra subprograms, which is the standard linear algebra library available on pretty much every platform, although it can be a bit of a pain to actually use it in C++ because it primarily has a bit of a pain to actually use it in C++ because it

primarily has a Fortran interface. So that is a separate linear algebra proposal that's sort of targeting a lower layer in the stack. We would presumably build the linear algebra proposal that Guy and Bob are working on on top of that lower level facility. Okay. Um, the, the MDRA paper is one, six, eight, four. And, uh, yes, it was in fact seen by Lug.

Um, and, uh, they, they want to see a revision of the paper according to the, uh, the, the notes that I have in front of me. Okay. Okay. I want to interrupt the discussion for just a moment to bring you a word from our sponsors. Backtrace is the only cross-platform crash and exception reporting solution

that automates all the manual work needed to capture, symbolicate, dedupe, classify, prioritize, and investigate crashes in one interface. Backtrace customers reduce engineering team time spent on figuring out what crashed, why, and whether it even matters by half or more. At the time of error, Backtrace customers reduce engineering team time spent on figuring out what crashed, why, and whether it even matters by half or more. At the time of error, Backtrace jumps into action,

capturing detailed dumps of app environmental state. It then analyzes process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. Whether you work on Linux, Windows, mobile, or gaming platforms, Backtrace can take pain out of crash handling. Check out their new Visual Studio extension for C++ developers. Companies like Fastly, Amazon, and

Comcast use Backtrace to improve software stability. It's free to try, minutes to set up, with no commitment necessary. Check them out at backtrace.io slash cppcast. Well, since you brought up Cologne, we have been talking about Cologne a little bit over the past few weeks.

We had Botan Bala and Tom Honorman do a trip report with us, and that trip report was based in a large part on us going over your excellent trip report that you posted to Reddit. Was there anything that you wanted to go over that you worked on personally that we maybe haven't discussed already?

Well, I should first note that those trip reports, while excellent, are not just me. In fact, we crowdsource it out to a very large team. There's approximately 30 to 40 people who are involved in writing those trip reports. We have a Google Doc that gets created either the night before or traditionally the morning of the closing plenary, and we just all fill it in. So I can't take all the credit, sadly. But you get all the Reddit gold for it. I do get all the Reddit gold for it. Yes, that is, that's why I do it, for the Reddit in fact whatever that even means at cologne i had a train um leaving cologne at 12 uh 42 to go to paris for my birthday and i was getting worried because plenary the

closing session of the committee meeting um uh it was like around 11 30 and we weren't over yet and but i couldn't leave because i needed to be there to post the reddit trip report the moment that we we closed for the week. Because that's what we do is we post it as soon as we're officially over. So I waited until like 1210 and that's when we actually finished up. And I pressed the send button and then I very rapidly left the room and ran to my train. Then the hotel was close enough to the train station that was doable? Yes, I made it there with a little bit of time to spare even um so did you guys talk about um modules uh uh when you did your cologne trip report

modules have come up many times they were approved right i mean yeah um so i think one of the one of the the more interesting things for me that happened at the clone meeting is we had a full day meeting of the tooling technical report, which will be a formal ISO document that is a separate document from the standard. And that document will record and describe the best practices for using modules and also describe some details of modules and module implementations that we just can't specify in the standard. Things like formats for dependency metadata, what different module build modes are, how they work, how things like fast dependency scanners work, sort of all the details of stuff that's really more details of the tooling and the build ecosystem than the actual structure of C++ source code itself. And so we made a lot of progress on this technical report, and we've made a lot of progress on getting all of the various stakeholders unified over the past couple

months. And we had a very productive session at Cologne. One of the outcomes of that session at Cologne is that we right now, we've determined that we do not want to pursue specifying a specific project structure or file naming convention um in this technical report but we do care a lot about making sure that um implicit module builds uh uh work quickly builds work well. And for that to be the case, that essentially mandates that what we care about is seeing fast dependency scanners be developed. Because if you're not going to enforce a particular project structure or file naming structure or module naming structure, and you want to just magically be able to build C++ projects that use modules without any explicit mapping describing what those modules are and the dependencies between them, well, then you need

some sort of magical tool that can quickly scan over your project and determine those dependencies. And it better be able to do that pretty quickly. And so we had consensus at the meeting that we are interested in that. We do care about implicit module builds. And because we don't want to specify a specific structure, that means that we just care about fast dependency scanners. So that was something that I think I did not, we as a group did not fully realize that we felt that way prior to the meeting. And it's good that we now have a clear direction for that, that'll really help us focus what goes into the modules ecosystem technical report.

And we made some progress on a few other things. Richard Smith had a paper, P1767, called Packaging Modules, although the name is a little misleading. It's really more about build system interchange. It proposes sort of a formal framework for thinking about how different package systems and build systems should exchange information about modular C++ projects. And I think it's a very important paper. If you care about packaging and modular builds, you should probably take a look at that paper. It's going to sort of be the basis, um, uh, uh, of our thinking on, uh, module packaging and, and builds in build system interchange interactions. That does sound like really significant because, I mean, I don't know, but I don't think there's anything else that currently recommends a way for compilers and tools to talk to each other, right?

I mean, that's unprecedented. That's correct. It is unprecedented. Yes. And that's one of the reasons why I think this work that we're doing in the tooling study group is going to be very significant going forward. If we can be successful in specifying some points of interoperability, like some of these formats that all the compilers will speak for build system interchange and dependency metadata, we might have a lot less implementation divergence in the details of how modules work between all the major implementations. And I think there could also be impacts for other languages and for the broader ecosystem, especially if we do end up settling on some build system interchange format. Essentially, we're talking about something that I think roughly amounts to a suggested, something like package config.

I don't want to say a standardized version of package config because it's not something that would be in the C++ standard. It would just be in this technical report, but that. So that's packages, where to find them modules hypothetically would it go so far as to like what's in the modules like would we get anything like a standardized or at least a recommended um name mangling convention um that i think is pretty unlikely to happen. And one of the reasons is that modules support two different ownership models. There's what's called strong module ownership, where entities that are within a module always have that module's name as part of their mangled name, even entities with external linkage. And then the weak ownership model, only entities with module linkage, so only entities that are visible only within a module,

have the module name as part of their ABI, as part of their mangled name. And different implementations want to pick different models. So Clang and GCC are planning to go with a weak ownership model, and MSVC is planning on going with a strong ownership model. that are exported from a module to another module without an ABI break, without changing how that entity is mangled. In the strong ownership model, it is an ABI break to move an exported entity between two different modules. And in the weak ownership model, it's not an ABI break. It's a tongue twister. Say module model five times fast.

Yes. Um, and there's then questions about like a, a standardized representation of compiled modules, I think is, is almost certainly, um, uh, something that would never happen. Um, in clang and LLVM, for example, the compiled module representation is literally like a serialized version of the Clang AST. It is super subject to change. Between different revisions of Clang, that representation might change. I believe Microsoft's representation is intended to be a little bit more stable. I'm not sure about GCC's.

I think it falls more in the line of what Cling and LLVM are doing. And each one of those implementations has different user bases and different design constraints. So I don't think that right now that there's any chance that we'll have some sort of standardized compiled module representation. Okay. Is this report on modules going to come out at the same time that the C++20 draft is finalized? The report is feature-driven, not deadline-driven. It will come out when it is ready. For it to be useful, we need to get sufficient field experience with modules. I think six months ago, we didn't really

have, we had 1.5 implementations. Now we have three fairly solid alpha or beta implementations of C++20 modules, and they're all maturing fairly rapidly. I think we probably have at least another year to 18 months before the technical report comes out for us to be able to get all the content for it and for us to get enough field experience with it to inform the technical report. One of the things about the technical report is it's intended to be a report. It's intended to be backed up by data and to have conclusions that draw upon that data. Okay. So we start off that discussion on modules by talking about the C++ Reddit trip report. And as we mentioned, you're one of the moderators of the C++ subreddit. Do you want to tell us more about your role as moderator there? Sure.

So I became the moderator of RCPP, I think, in 2015 or 2016. I actually just asked to become a moderator. There was a particular flame war that happened on the subreddit, and I had calmed things down a little bit, and I just suggested to the mods, like, hey, I think we could use some more moderators. Why don't you all make me a moderator? And that worked out.

So I've been doing it for two or three years now. There's about five or six other moderators, about three to four of us who are particularly active. STL, who is one of the main maintainers of the Microsoft Standard Library, is one of the moderators. There's a fellow who I don't actually know his his name in the real world and if he's if he's listening to this i will um applaud this and later uh but his his handle is c c l e r o t h um i think um and uh he's a he's a game developer he's been a

moderator he got me he got uh made moderator around the same time I was. The biggest thing that we probably do is deal with off-topic posts. So there's like a billion giant warning signs on the Reddit and on the submission page that say, please don't submit homework questions. We get about three or four homework questions a day. Okay. So we try to clear those out because our CPP is, it's really intended to be a place for C++, like professional C++ developers,

enthusiasts C++ developers, anybody who's interested in C++ to come and talk about the latest developments in C++ evolution, C++ developers, anybody who's interested in C++ to come and talk about the latest developments in C++ evolution, C++ libraries, C++ community. It's not intended to be a place to come to get, you know, help on your C++ problems. It's not Stack Overflow. Right. It's not Stack Overflow. And there is a separate subreddit our cpp questions for that um that's not to say that that asking a question in our cpp is always off topic for

example if you write a post that asks like a very deep question about c++ or even a not so deep question but just you you have a very thoughtful post and there's like stuff there to discuss that's completely fine um it is at the end of the day a discussion format and there's like stuff there to discuss. That's completely fine. It is at the end of the day a discussion format. So it's fine for you to ask a question if your question is going to spur discussion. But if you're just saying, hey, I have this compiler error. Can you help me fix it? We're not the place for that.

There's also the actual like moderation part of the job. So there are times when the subreddit can get a little heated. And so we have to keep an eye out for that and try to encourage people to be civil. I'd say, I think that there's room for improvement in sort of the culture of the subreddit. We could do a little bit better job of being welcoming to people. But I think we've come a long way since when I

first started using RCPP. And I think generally speaking, discussions on RCPP are pretty thoughtful and fairly technical. One of the things that we look for as moderators is when does a discussion stop being a technical disagreement and start becoming a personal disagreement? And that's when it's time for it to not be happening on my subreddit. Your subreddit. I say that as a parent to a child. And I'm sure I will get flack on Twitter for that comment.

Are there any other online C++ communities that you're involved with, moderate or anything? Yes, I am one of the admins for the CPP Lang Slack. I will say I am not super active there, which is actually a good public service announcement. If you see something on the C++ language Slack that you believe needs moderation, it's good to call it out or to notify a mod or to use the app mods handle, because there's a lot of stuff that gets said on that Slack. Like Reddit, there's maybe 10 or 20

posts a day. I can just look at all of those. I can't be in every room on Slack. I can't keep track of all of that. So I think it's much more difficult to moderate a slack instance than it is to moderate reddit um yeah but i just put it up just out of curiosity there's currently 13 000 people in general yeah yeah oh wow yeah um and uh and yeah those are the two like places where i'm some sort of moderator. And I'm also active on the Include C++ Discord channel and Twitter, of course. I'm on the tweets a lot. That you don't moderate, though.

That I do not moderate. It'd be a shame there's no one to moderate Twitter. Every now and then it would be handy. Yes, it certainly would be a shame there's no one to moderate Twitter. Every now and then it would be handy. Yes, it certainly would be. You mentioned in your bio you're also program chair for CBPCon and C++Now. C++Now effectively just ended as far as the timeline of C++ events over the year ago. And CBPCon is starting very soon. Yes, I have to go finish implementing all the code for my talk.

So what talk are you giving? I'm giving a talk about the C++20 synchronization library, which is a combination of various new synchronization and communication primitives and enhancements to old synchronization primitives, all of which is landing in C++ 20. So the atomic wait and notify API, semaphore types, barriers, latches, a floating point, atomics,

atomic ref. I'm sure I'm forgetting one or two things. Someone will point them out during the talk. Yeah. So I think I have a cool idea for how I'm going to do the talk. Originally, I was going to try to do the talk as a couple of different examples for each thing. But now I'm thinking I can build a little mini tasking runtime that I can use. I would actually need all of those facilities I just mentioned at some point in that project.

So I'm thinking I'll maybe just do the talk as one big long example. That sounds great. I will come and see whether or not you succeed at that. Actually, I can't promise that because I don't look at the schedule at all. But it does sound like a great idea.

I hope it proves to be one. Anything else you're looking forward to with CppCon this year at the new location? So, I mean, I think this is going to be a very exciting year for us. We have a particularly strong program. This is the first year when making the final programming decisions was really, truly agonizing torture. It's usually painful, but this year it was, it was, it was very difficult to make those final decisions. We had to say no to a lot of good talks because we just had that many good talks. So I think we have a very strong program this year.

I'm glad that the number of submissions we get every year continues to increase because that helps us make a better program. When we're making difficult decisions, that's how I know we have a good program. I think we've got a lot of really good C++20 content showing up this year. And, yeah, I think just in general, it's a strong program. We have a lot more talks from the, um, like low latency and financial world than we've had in past years. I've always wanted to have some more of that. Um, I'm trying to think of other particularly, we, of course we always have really good concurrency and parallels and talks.

That's true this year too. Um, and, and yeah, it's, it's a good program. Um, I would, I would encourage people to come and attend it's a new venue, it should be super exciting I'm really looking forward to it It looks like we've got upwards to 8 tracks depending on the particular time slot Yes, that is correct

This started out as a 5 track track conference and it became a six track conference then it became a 6.5 track conference then a seven track conference now we're basically up to eight tracks and and one of the reasons for that is that we've added a track um that i should have mentioned but thank you for reminding me um called back to basics the back to basics track is essentially it's it's um talks on um sort of fundamental c++ Oh, yes. a lot of people who come to cgp con who are not you know senior yeah who aren't you know your senior c++ programmer with 10 to 15 years of experience but i also think it's the case that even if you are very experienced i'd still encourage you to check out this track because i think um a lot of those basics have either changed since you learned them um or there's some like detail of

them that you may not have never known um so i'm very excited for it i think in our first year at cpp con people didn't know um where to target talks people thought oh we need talks to be really really really basic for the the masses and we got a lot of feedback on talks that first year, which was basically this stuff is too basic. And I think that we might have course corrected a little bit too hard, that we veered away from fundamentals talks a little bit after the first year. And now we've really had over the years a lot of really great talks, but talks on

intermediate to advanced subjects. We have not had a lot of talks on beginner material. Um, and I think the return of that content will be good for the conference and good for people who are watching on YouTube. Cool. Okay. Well, is there anything else you wanted to go over today before we let you go, Bryce? Um, that's, that's it. It's all I can think of. Okay. Well, it's been great having you on the show again today. It's been great being here. Thanks for coming on. Thanks so much for listening in as we chat about C++.

We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter.

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