CppCast - Mdspan and Too Cute C++ Tricks

Episode Date: November 25, 2021

Rob and Conor are joined by Daisy Hollman. They first talk about C++23's approaching feature freeze including Daisy's work on the mdspan proposal. Then they talk to Daisy about her recent 'too cute' CppCon talk and whether you should be writing cute code in production. News JetBrains CppCon Talks C++23: Near the Finish Line Cmake 3.22.0 available for download Links p0009 mdspan Daisy Hollman - What you can learn from being too cute - Meeting C++ online Petrify App PMD Source Code Analyzer #include Sponsors Use code JetBrainsForCppCast during checkout at JetBrains.com for a 25% discount

Episode 326 of CppCast with guest Daisy Holman, recorded November 23rd, 2021. JetBrains is offering a 25% discount for purchasing or renewing a yearly individual license on the C++ tool of your choice. CLion, ReSharper, C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at www.jetbrains.com. In this episode, we discuss C++23 approaching its feature freeze. Then we talk to Daisy Holman. Daisy talks to us about MD-SPAN and cute C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right, Rob. How are you doing?

I'm doing okay. It's been a while. We were doing the math before we started. We've actually not recorded together for like three weeks. Yeah. Well, I mean, it's like the longest stretch in several years at this point. Yeah. So I'm sure everyone who's a regular listener saw we did miss a week last week. So I apologize for that.

But we were both kind of getting back from vacation and getting in the swing of things, and it just didn't work out. Yeah. And hopefully Connor made an acceptably good uh co-host yeah connor was uh great to have when we had a gosh burr on uh talking about deducing this a few weeks ago yeah he was good cool all right so at the top of every episode i'd like to read a piece of feedback um since we did miss last week's episode i i put out a tweet about that and we got a couple nice responses this one was from Guy Davidson

saying best wishes everyone needs a rest sometimes by the way if you want to talk about the rainbow flower book I wrote with Kate Gregory it's due out December 23rd we'd love to be on the show and yeah we're looking forward to talking to Kate and Guy within the next few weeks about the new

beautiful C++ book. I appreciate that it has a beautiful cover. It does have a very beautiful cover. I'm looking forward to hearing exactly what the book covers. Yeah, me too. All right. 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 cppcast.com.

And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Dr. Daisy Holman. Dr. Holman has been involved in the C++ Stands Committee since 2016, where she has made contributions to a wide range of library and language features, including proposals related to executors, atomics, generic programming, futures, and multidimensional rays. Since receiving her PhD in quantum chemistry in 2013, her research has focused primarily on parallel and concurrent programming models,

though a broader focus on general accessibility of complex abstractions has become her focus in more recent years. She currently works on C++ language and library design at Google, where she continues to focus on providing broad accessibility of programming models and library interfaces, with a particular focus on design for diversity and inclusivity. Daisy, welcome to the show. Hi, thanks so much for having me. Can you tell me what the heck quantum chemistry is?

Quantum chemistry is just quantum mechanics applied to chemistry. So because you happen to be studying the Schrodinger equation of electrons, they call it chemistry because chemistry is really about electrons. But most of my classes I took from either the physics department or specifically from quantum chemists. So it was like, you know, it's kind of a mix. I tell people quantum mechanics sometimes. It's just the way a PhD is in because it's a little bit easier for people.

What was the, did you do a thesis PhD based? My dissertation was a bunch of my papers smashed together. And I needed to come up with an underlying theme. So I think I called it like correlated electrons and chemical systems, which is like another fancy way of saying chemistry. Oh, okay. But yeah, it's really interesting. I think a lot of people end up in programming models out of quantum chemistry

just because there's this demand for scale coming from the biology side, and there's this demand for precision coming from the physics side. And so the intersection of those means you're doing really complicated problems on really large computers, which means you have to design complicated problems on really large computers, which means you have to design very, very careful abstraction layers. And that's how I ended up in C++ and in C++ programming models design. Wow, very cool. All right. Well, Daisy, we got a couple news articles to discuss. Feel free to comment on any of these and we'll start talking more about your

CPVCon talk and some of the ISO papers you worked on and stuff like that, okay? Sounds great. All right. So the first thing we have is a link to JetBrains and their CppCon 2021 videos. I think when I had Gasper and Connor on in the last episode, we were talking about where the CppCon videos are currently located, because you can't just go to YouTube yet until they're all published, I guess. But

JetBrains has this link where you can go and peruse all the videos that have been published so far. So I wanted to make sure we put that in the show notes. Yeah, it looks like it's specifically the plenaries. I was just looking and it looks like it is more than that. On the bottom, underneath the plenaries, is a link that's just CppCon 2021 Talks. And that opens a YouTube playlist, which includes all the plenaries. And then I see Eric Niebler's two talks on working with asynchrony generally. And it says there's 45 talks or 45 videos total. So maybe that's all like the day one videos. I'm not sure.

I didn't see it was a playlist. I saw it was Eric's. I knew Eric's went up. Yeah. I knew the plenaries were up. Yeah, so for all those listeners looking for watching more of the CPCon videos, definitely look for this playlist on the bottom because, yeah, 45 videos up so far.

All right. And then the next thing we have is a Reddit post and this is C++23 near the finish line. And it's kind of going over the progress as we approach the so-called feature freeze of C++23. And Daisy, you're telling us that you've been kind of involved in a lot of these right? Yeah I mean I've kind of taken a little bit of a break from C++ committee involvement when I moved to Google from the National Labs but a lot of these papers are things that I was involved in at one point or another and the post I think reminded me of why i really enjoyed contributing to these things and then the comment section reminded me why i've been taking a break yeah yeah um so stood

execution um i think it's an excellent paper um i don't want to start a flame war in the comments of your podcast. That doesn't tend to happen for the podcast, just so you know. Oh, that's good. It doesn't tend to. It has once or twice. It depends on who the guest is. I think Bryce got some comments aimed at him when we had him on talking about ISO. Yeah.

Yeah, yeah, yeah. So, I mean, this is, SID execution is, I think, a big underlying topic of this post. Like, why is this getting so much time when it's, quote-unquote, so new? And this is kind of the replacement for executors, right? Right. It's the cleaning up of the compromise executor's proposal, which was P1194, which was a compromise between P443 and 16-something that was the Eric Kirk and Lewis's paper back in 2018. 443 was already a compromise

executor proposal between three proposals before that. One from NVIDIA, one from Chris... What's his last name? He's Australian. I'm blanking on his name and i should know this but um christabella i believe is what you're looking for no not christabella the other australian chris oh i'm sorry no um he works in finance does uh bustasio um anyway i'm not sure. He's going to be really upset that I forgot his name.

And then Google was actually involved early, early in this. I think the first paper on executors was 2012, right? Oh, wow. That's gracious. I mean, I think a lot of this post is talking about why is executors getting so much time when, you know, the paper that the discussion is about is only five months old, which is, and actually the original poster mentions me in one of the comments says, like, I went back and watched Daisy Holman's history of executors talk from 2019. And I don't think that the 2300 closely enough relates to, you know, the history of executors, which judge for yourself on that. I don't know. But anyway, that and then there's a lot about

P triple oh nine in here, which is the multidimensional array. And then basically anyone coming from scientific computing, the only thing they can comment about is, well, why don't we already have linear algebra? This is ridiculous. It's been standardized since 1979. Why isn't it part of the C++ standard? And I agree.

I'm not in scientific computing anymore, but I think everyone in scientific computing is just shocked that there's no standard linear algebra and hasn't been yet, even though the BLAST standard is effectively as old as C++ itself. That's the typical reactions we get to those papers every time they come out. It's like people who haven't been involved in the executor process are like, why are we talking about it so much?

This seems super new, and it's because every time that we talk about it, there's enough objections that we have to write a new paper that makes a compromise. And so it looks always looks new. And then the talking points on linear algebra and multidimensional arrays are always just like one community being like, how in the world is this not already in the standard? And another community being like, why are we wasting time putting this in the standard? Yeah. Well, if you look at the MD span, what does that say? 74 months that the paper's been in process?

So I'm one of the probably five people who at one point in time called P-triple-oh-nine my baby. I kind of carried the lead of the torch for that for about two years and yeah I mean part of that was that there were a lot of people coming into that originally from scientific computing who had very little programming languages experience trying to standardize something and we were trying to standardize

something very very complicated so I actually wrote the production implementation of MD-SPAN that's being used at the National Labs now. And hopefully, if we can work out all the politics, it's going to be contributed to all three standard library implementations. MSVC might be a stretch, but the other two it should be able to be contributed to. And it is, I mean,

I think, personally, it's a contender for the most complicated piece of code that's going to go into the standard library right next to std tuple. Maybe some of the constructors of std tuple are a little bit more complicated, but there's

sub-md span is just an incredibly messy bit of metaprogramming that has to work very generically between static and dynamic extents and has to maintain them through slicing and all kinds of other things. And it's an incredibly complicated paper. and often library proposals get written as you write some library feature in code and then you try and back out the actual standardese for it. And this is kind of sort of that, except for the standardese is just immensely complex for this paper.

So that's another reason why it's so old. So it was like had people who didn't know how to write standardese when they started it um working on it and then like um like this this paper actually was originally an n-numbered paper so it actually predates p-numbered papers um oh wow but and then and then like yeah it's been through some changes since then um it's been on the cusp it was on the cusp of making c++ 17 it was on the cusp of making C++ 17. It was on the cusp of making C++ 20. It is now really on the cusp

because I think we have several people who really know what they're doing involved in it. I think it's actually going to make C++ 23, especially now that we have a reference production implementation that is in use at the national labs, in production code, being run on giant supercomputers. There's really a pretty compelling case for it to make the standard. So I'm excited about that. It's in the top category of papers that are expected to make it,

right? Yeah. It's not in the no category. Right. And hopefully, it's,'s you know it's kind of in that category like multi-dimensional arrays in general are in that category of things that are really hard to get through the standard because they are it's simple enough that everyone has an opinion on it right so like one of the most contentious things that we had in the standard in the last standard was like size types right um like size types for containers that discussion was epic and super long and it's because it's so small and simple that everyone has an opinion and in fairness it's not that everyone like a lot of people have a relatively informed opinion on it it's just that it's it's it's simple enough that people can

can form opinions on it pretty easily whereas a lot of more complicated things like um i don't know uh uh the barriers work for instance that came out of SG1, std barrier. That has some really complicated things involving memory orders. And so a lot of people just are like, yeah, sure, the experts looked at it. Sounds good to me, right? Whereas I don't know who's an expert on size types, right? And multidimensional arrays are kind of like that, right? Everyone uses arrays, so everyone kind of has an idea of what they think that multidimensional arrays should look like. And so you get a lot of feedback, you get a lot of opinions,

and you have to handle those opinions. And that's not a bad thing, but it's not a good thing for velocity, at least. I have a random aside here, tangent, I guess, a little bit. But MD-SPAN, can it handle an arbitrary number of dimensions? Is that how it's written? It can. Okay. I tested my reference implementation.

So I did a paper on this for supercomputing in 2019. It was a supercomputing workshop. I can get you a link to it for the show notes but where we so I mean high performance competing people are very skeptical of abstraction they're like if it's adding five instructions or something like that then I'm out

I'd rather have the code be less readable or something like that which okay we can talk about whether or not that's a really good or healthy position for them to be having, but a lot of them do. A lot of them are skeptical of C++ in general. So in this paper, we basically showed with several microbenchmarks that the MD-SPAN was producing the same code and was microbenchmarking at exactly the same speed um as like the same uh thing done with just pointer arithmetic um with like raw pointers um and one of the things

we did with for that paper was just push the limits of what the compiler could handle in terms of inlining and in terms of constant propagation. I got GCC to constant propagate dereferencing a sum over a 74-dimensional array. Now, most of the dimensions were size 1, and it was able to constant uh, constant propagate the entire array, dereference, constant propagate the entire sum and compile the function into like return 42 or something like that. You know, if the sum was actually 42 and if it was given constants. Um, so it is actually very powerful and the ability of compilers to cut through abstraction is just way beyond what most people estimate it is.

Way, way beyond. People are skeptical that, like, a compiler can cut through an eight-dimensional array, and I'm just like, here's 74. Right. And it is all constexpr-correct, so all the things that are supposed to be marked constexpr are marked constexpr,

and the compiler can do these things inside of static asserts, albeit very, very, very slowly. But yeah, so that was actually really fun. It's the hardest piece of code I've ever written in my life. I don't know that I'll ever write anything that hard again. Maybe, hopefully not. Maybe, hopefully so. I mean, I enjoyed it a lot.

It was a lot of fun, but this is definitely a challenge. That's a fascinating point, you know, because you also pointed out that it's simple, quote unquote, simple enough that everyone feels like they can have an opinion, but clearly they don't understand the implementation complexity involved. Right. Especially if you're doing this thing as a library feature and not with any language support, right? So, and I think it is correctly done as a library feature, don't get me wrong. I think that a lot of the customization point design and the use of generic programming in P-triple-O-9

is in line with the standard template library as it was originally envisioned, right? In line with the ideas behind SID vector in terms of the ability to customize for different domains and provide reasonable defaults. All right. So last thing we want to talk about was this CMake 3.22 release announcement.

Anything big going on in this release, Jason? Yeah, I was just going to say, you usually rely on me to point out what was big in the CMake release. I mean, it looks like my main takeaway from this one, because there's so many like little details, like whether or not you can set a variable to say that a find package to a future package name must be a required like to override some of the features of find package or whatever. A lot of these things just make me go, you know, like once a year, you just need to go over your CMake code and be like, is there a better way to do this with modern CMake today? It's just like your C++ code.

You need to do a modernization pass every now and then with your CMake. Also, I think interesting to note that Visual Studio 2010 is officially being dropped from CMake. I don't think I've ever noticed CMake deprecate a feature like that before. Well, it must be every few years getting rid of old Visual Studio versions, though. I'm assuming they don't support anything prior to 2010, right? I don't know. I guess not.

But I mean, I just hadn't noticed it before, that's all. Daisy, do you have any opinion here on this CMake release? Do you use CMake? I use CMake pretty religiously at the National Labs. I was a strong advocate for CMake, just as like, it's the best that we've got, let's just use it and coalesce around it. And it took me about a week and a half of being at Google

to realize I was completely wrong. And Basil is on to something that is much cleaner and more scalable. So that's all I'll say. I'm drinking the Kool-Aid now, and I think Bazel is fantastic, and everyone should, who's considering switching build systems,

especially now that Bazel has CMake compatibility and can interact with other CMake libraries, so you can just import CMake directly, you can import AutoTools stuff directly. I would consider... If you're already on CMake, it's not worth the effort, I don't think, to switch. Unless you're really considering completely

overhauling your CMake. I let build systems experts do build system-y stuff. Stick to what I'm good at. Maybe we should... I think we have. I was going to say maybe we should episode we did i think we have i was gonna say maybe we should do an update on some of those topics at some point all right well daisy i think to start off we wanted to we already talked a lot about md spam which is one of the things we want

to talk about but the other thing we want to talk about was um your cpp con talk the uh two cute c plus plus tricks uh what was the inspiration for that talk? The interesting thing is I think this actually started while I was writing. I think my very first one started while I was writing or maintaining the P0009 production implementation because there's some kind of scary things you have to do with parameter packs just to make empty span work and I was just like wow this is like something I

never should be writing in real code I have to write it here because it's standard library code but I bet people would be interested to know that this works this way. I think really why it got a lot of uptake is because I just happened to at that time be experimenting with a new screenshot generator that could like generate screenshots of code snippets. I think it's called Petrify on Mac. I'm very happy with it. You should, we can put a link in the show notes i guess um not endorsed or anything like that i don't even know if i think it's a free tool anyway um but there um i think because people could just read the code right there um and it was short enough to like feel like a tweet sized thing people really seemed to like it and were interested in it and um so i started doing it kind

of regularly. It was kind of addicting a little bit, you know, how social media can be. But it was also fun to see what people were learning, see what people had to add to this. Richard Smith started chiming in every now and then. Some of my favorite tricks were the ones that, you know, Richard responded something to. And then I kind of riffed off ones that you know richard responded something to and then i kind of riffed off of that into a new trick or something like that um but yeah it's um i don't do them daily or regularly sometimes like i went six months without doing one just recently um i call it the cute c++ trick of the day but it's like day just happens to be the time period I chose at the time. And I have done them like

one every day for a week before, but now I feel like my own bar for quality for putting one of them out has gotten to be so high that I kind of agonize over them for weeks. I have like four or five in the works right now, but they're not

quite pithy enough, and they're not quite pithy enough and they don't quite demonstrate the concept clear enough. So I'm kind of trying to work them down into these nice little catchy things. But it's fun. It's a fun little side project. I think people are learning a lot from them and I think that's really cool, the cool part for me.

That's funny. It makes me think of sometimes people comment like making a well-done lightning talk can take as much effort as like a keynote. And that's what you're talking about. Basically, tiny little lightning talk snippets that you're trying to refine to the perfect thing. Exactly, exactly. And it has to fit into the image that kind of, you know, pops up on people's phone without them having to click on it because otherwise people won't click on it. I've kind of looked at the numbers of how long that is and it's about 20-ish lines.

So trying to say something profound that's surprising to people in C++ in 20 lines is hard. I think Shafiq does a really good job of it in his C++ polls or whatever. It's the same kind of thing. So yeah, I think it's a fun little challenge. I think Matt Kulikundis had the greatest name for it.

You've heard of CodeGolf, right? Where you're trying to actually get the number of characters down. And this isn't really about getting the number of characters down. It's about really getting the most creativity into the fewest kind of lines or whatever and so he called it code mini golf right it's like you're trying to hit it off the windmill through the loopy loop and into the hole or something like that you know um which i think is a really cute idea um and i think it's a really fun way to learn like i think code golf is a really fun way to learn code too it's gotten to be pretty intense if you've ever done CodeGolf seriously

but I think CodeMiniGolf is another cute way to learn new things about a language So how many of these did you actually present in your talk? Five Five plus one bonus one that was part of the same category as another one but my outline had 12 or 10 I think I meant to, well, five plus like one bonus one that was part of the same category as another one. But my outline had 12 or 10, I think.

And I got the feedback that like, this looks like a three-hour talk. And I was like, nah, this isn't a three-hour talk. And then I put it together and I was like, how the heck am I going to fit these five into one hour? I actually had slides for six, but there's no way. I was rushing just to get through those five in an hour. But I think my plan is I titled it Part 1 of N. Right. As, like, I think Tony Van Eerd does this with a lot of his talks. Yeah, a lock-free, multi-threaded queue.

It's the longest-running one that I know of, anyhow. Yeah, and so I probably will do another one next year. I mean, I think it was well enough received. I'm very happy that it was really well received because I really enjoyed making it. I really enjoyed talking about it. So I felt a lot more nervousness around the talk than I usually do because I was just like,

I really want this to go well because that means I get to do it again. I'm excited about that. It's like the gift that keeps giving. How many of the cute C++ tricks do you have? How many have you put out in tweet form at least? I haven't counted, but

I think there... I went through and I think there are about... While I was making this talk, I think there are about 30 that I'd like to talk about. Okay. Counting ones that I haven't put out yet. Because at least four or five talks. They kind of have floating around in my head.

Yeah. Right, it's at least four or five talks. Some of them start to overlap with each other. A lot of them are like boiled down to really interesting parameter pack tricks that are pretty redundant. And like this is good. This is good that we're coalescing around like certain little idioms that people can reuse. And then like expanding on the idiom in a creative way.

And so it's going to be interesting to figure out how to organize those into self-contained talks. Because like I have to first present the idiom and then present all the ways to expand on the idiom. So we'll see. We'll end up the discussion for just a moment to bring you a word from our sponsor. CLion is a smart cross-platform IDE for C and C++

by JetBrains. It understands all the tricky parts of modern C++ and integrates with essential tools from the C++ ecosystem, like CMake, Clang tools, unit testing frameworks, sanitizers, profilers, Doxygen, and many others. C-Lion runs its code analysis to detect unused and unreachable code, dangling pointers, missing typecasts, no matching function overloads, and many other issues. They are detected instantly as you type and can be fixed with a touch of a button while the IDE correctly handles the changes throughout the project. No matter what you're involved in, embedded development, CUDA, or Qt, you'll find specialized support for it. You can run debug your apps locally, remotely, or on a microcontroller, as well as benefit from the collaborative development service.

Download the trial version and learn more at jb.gg slash cppcast dash cline. Use the coupon code jetbrains for cppcast during checkout for a 25% discount off the price of a yearly individual license. So obviously listeners should go and watch the talk on youtube once it's available um but is there any trick that you kind of wish you had been able to get to in in your talk that you wanted to share one that kind of would work in audio format sharing yeah so i have one that i've been working on for a while that i don't really i think i tweeted something about it at one point, but I wasn't very happy with it. So I want to somehow summarize the fact that lambdas in unevaluated contexts in C++20 really, really make the design of metaprogramming libraries

super-duper easy compared to what they used to. Because you can basically just do decal value, decal val of the unevaluated lambda in some wrapper, and then use that as like a meta lambda, right? So I think even dating back to Boost NPL, people have done meta lambdas, right? Just because they're super useful for predicates of meta metaprogramming algorithms and and things like that but i've been building out a library i won't say the name publicly of it because i'm hoping to do like a big release of it at some point but i've been building out a library um not really designed around like the fastest metaprogramming

ever but really designed around like the cutest metaprogramming ever but really designed around like the cutest metaprogramming implementations of algorithms and one of the base um idioms in it is is reuse of of lambdas for metaprogramming and i think it makes for surprisingly readable metal metaprograms i did tweet out like a um version of conway's game of life um using template metaprogramming um like compile time conway's game of life in a while back using that library and it's only like 50 lines um which is of arguably readable metaprogramming i think arguably readable is better than most metaprogramming, I think. Arguably readable is better than most metaprogramming. What? Arguably readable is better than most metaprogramming. Yeah, arguably readable.

I mean, I think doing readable metaprogramming is one of the most interesting challenges for me in C++. I think there's a lot of people that just say, if there's something you would call metaprogramming, you shouldn't be doing it. And I think it's possible that there are code bases where that's true. But even in those code bases, you have to fundamentally answer the question of there are some pieces of code that you have the choice of metaprogramming, copy-paste, or external code generation. And all three of those are evil in their own ways.

You have to choose the least of the three evils. Hopefully with some reflection and reification stuff coming and generative metaprogramming, this is going to become a lot easier by C++ 26, 29. Yeah, maybe. That's another discussion about the status of that. But the reality is that if you work on a code base now and this question comes up,

you should be asking the question, right? You should be asking, is copy pasted code more maintainable here than metaprogramming? And if you're not at least asking that question, you're probably making a mistake. If you're categorically ruling out metaprogramming because it's complicated,

because it'll slow down your compiler, because blah, blah, blah. Compile time is a cost. Developer time is a cost. Weigh your costs. Figure something out. But I think along those lines, part of the reason why metaprogramming gets such a bad rap is that people no one really focuses heavily on readable metaprogramming right people focus on functional like metaprogramming that does the job and you put off somewhere or people focus on avoiding

metaprogramming but like there's like But where's the style guide for how to write readable metaprogramming code, readable generative code? I think there needs to be a lot more talk about that. I think I'd love to give a talk on that sometime. That's one of my lists of things, like how to write readable metacode when you have to, and only when you have to. I don't know how we got on that topic, I'm sorry.'m sorry no it's fine though but that's how many people think of templates as write only code which is kind of i think what you're getting at there and it certainly doesn't have to be yeah right

absolutely um and also like i definitely would draw the distinction between generic programming and template metaprogramming like right people say, because the keyword template's being used, it's template metaprogramming. And I think you are missing out on a lot of C++ if you think that way. I totally agree with you. It is also true that I think a lot of day-to-day developers don't use templates because they're writing code

that doesn't need it. So I think that's also something for us to keep in mind is the ivory tower C++ people who talk about C++ for fun on a podcast. The reality of a lot of C++ developers day-to-day is that they don't use templates. And so figuring out how to design C++ for those people as well as for us is interesting. I think there's a lot of day-to-day C++ programmers who don't use functions either.

And just getting them to use any kind of abstraction would be handy. I'm sorry. I will stop. Anyhow. No, I totally get it. A lot of C++ programmers do a lot of copy-pasting. I wish I had a CI tool that would go through and say, like, are you sure you wanted to copy-paste this? Oh, I can help you with that.

There's the copy-paste detector, CPD, copy-paste detector. Oh, really? Yes, it's a tool written in Java. it's the pm pmd cpd i figure what pmd stands for their little icon says don't shoot the messenger um and uh it does because there's well-known algorithms for doing copy paste detection and it implements one of those algorithms and can give you a full report within you know guidelines for how long of a snippet you care about and how many tokens have to be the same or different because it looks for even the same chunk changed with just a couple of tokens changed in it haven't we also mentioned pbs studio articles where they do copy

paste detection but see that oh you you know copy pasted this code but you forgot to change this variable or something like that yeah but i think that only works within like one function scope okay i could be wrong i don't think there's does a project wide which i think is what daisy wants and this is beautiful you should try running once you have this in their ci it'll make you sad when you run it trust me it will make you sad yes oh this is this is beautiful stuff this is this is what people need to be using um i yeah this is why i'm a proponent of you know light meta light readable maintainable metaprogramming um because copy paste code is just impossible to maintain yeah i've dealt with so much of it but back to your talk sorry no no that's uh um one thing i was curious about is because you you titled the talk like two cute tricks and you kind of have this implication

that these are things that we shouldn't be doing in real code and i'm in the back of the room watching your talk and well i'm sitting with a certain group of people who will go nameless that are like, yeah, we do that. Yeah, we do that. We do that. So where's the line drawn between these are tricks that you might need depending on what you're doing and no, really, you shouldn't be doing this? Well, it really code always depends on the reader, right? Okay. depends on the reader, right? Some code goes from, like, the lifespans of code can be anywhere

from, you know, 10 minutes for a script or for, like, essentially a bash command to, like, you know, indefinite, essentially, right? And anything that is long-lived and you don't, has an unbounded set of readers

should be unsurprising to any reader you can imagine, right? Anyone who would be hired by your company with good enough C++ to be hired by your company should be not surprised by your code, right? I think good software engineering is unsurprising. I think good tweets are surprising. No one's going to retweet something that's not surprising, right? That's a good point.

Yeah. So I think fundamentally, I'm not disagreeing with the fact that some of these are useful in real code from time to time. I certainly have enumerated a parameter pack before the way that we did it. I think that's the only reasonable way to enumerate a parameter pack in C++ now. I wish we had 4... I wish we had square bracket indexing of parameter packs.

I'm not entirely sure why we don't. I think that those things could be added relatively easily. But I I mean time mostly is that people haven't had time to add those things. But I, I mean, time mostly is that people haven't had time to add those things. But I, I think that, yeah, if some of these things would not be surprising to your reader, like, for instance, the static lambda one, that's the one that I most got the, the immediately evaluated lambda in a static initializer has call once semantics. That's the one that got the most feedback of like,

well, I've done that before. And there's a couple of reasons why people have done that before. It is actually faster than std call once. Did you figure that out? I was wondering, yeah. Yeah. I didn't do any micro benchmarks on it, but if you look at the code generated on Godbolt, it's pretty easy to see why people would at least think that right um i should run some pretty rigorous micro benchmarks on it part of the problem is that like

how do you run a micro benchmark on something that's run once in right well um well most of the cost is well okay just a guess but the run once isn't the expense, right? The actual expense is how much does it cost to check to see if it needs to be run the next time. So I think you could do molecular benchmark on it and just attempt to call it many times. Oh, I see. That's interesting. I could be wrong. Yeah, that's interesting. I think there's a pthread call once that gets used for std call once and I think that jump is actually slower although I would expect not appreciably I think that most of this code

shouldn't be in critical paths but that is a good point that's the thing we should benchmark what is the cost after the first invocation I suspect it's pretty trivial in both cases but yeah i don't know that's the thing we should benchmark i definitely see why people would think that though because it doesn't get inlined the call to double underscore cxa guard acquire um is inlined looks like a compiler intrinsic

more than the pthread call once thing. I don't know. That's a good question. I should have gone and benchmarked it. But my first thought was something that is called once shouldn't be in a critical path. But you actually make an absolutely good point. It could entirely be in a critical path, just not the calling once part.

I see static objects in the critical path very often. You do too. I don't know if I've ever seen call once in the critical path. So I know I have a feel for the cost of a static object being the critical path because that can actually be a real expense. But I've like never used call once before. So I don't have any context for that. Yeah, I haven't, I haven't benchmarked either of them a lot. But and if anything, that's a static initializer in a critical path, I really want it to be a constexpr initializer, probably

constant evaluated initializer constant expression um so i you know probably would have avoided this kind of pattern but that's the one i've seen people do a lot um but i i think that like yeah all code should depend on the reader right none of this is too cute if your code is going to last 10 minutes right um but pretty much all of this is too cute if your code is going to last 10 minutes. But pretty much all of this is, if you're writing code that has to last for generations, even if you can't use std call once, you should wrap this immediately evaluated lambda trick in something called my library colon colon call once

and then use the immediately evaluated lambda there. At least isolate the part that's too cute. And then put a profuse comment like, you know, section blah, blah, blah, blah, blah of the C++ standard guarantees that this will be evaluated once. By the first thread that encounters it, all other threads will wait for the initializer to complete.

Exits via an exception will cause the next thread that reaches it to evaluate it, blah, blah, blah. Write out something. Be very verbose. Keep in mind that your code is going to last for generations, potentially, at many companies. Certainly at Google, we have to do that.

Google has enormous amounts of code, enormous numbers of developers, and enormously long-lived code. We're still dealing with fallout from things that we wrote in 2006. For the most part, a lot of that has been cleaned up. We have some of the best code janitors in the world. We call them code gardeners. Some of the best research on that is being done at Google.

Is that literally people who just go through and make sure everything stays tidy? Yeah, absolutely. I kind of want that job. I think I can just imagine myself like a Zen gardener going through the code base. I mean, I think that team is hiring, so I'm not actually looking for a real job. I know, I know, but, um, they're probably our listeners who are. And if that's something that you're passionate about,

Google is the best place in the world to do it, I'll be honest. Shameless plug, but yeah. How has the transition been from the National Labs to Google aside from the brainwashing on Basil? I mean, I'm drinking the Kool-Aid pretty heavily. I'm in a fantastic part of Google. I know that every company that is as large as Google has people that you'll disagree with.

I know that every company has good parts and every company has bad parts. I'm not going to comment on that, of course. I will say that the part of Google that I'm in, I work under Chandler. I work with Titus, both of whom most of your listeners will know of. I'm very happy in that part of Google.

I'm very happy with the variety of things I get to work with. I'm very happy with the developers I get to work with. Those of you who know me personally know that I'm very passionate about diversity and inclusivity and getting to actually work at a company that has enough developers that we can actually talk about things like, what does it mean to write inclusive code? What does it mean to write code that is readable by more than just cis white men? What does it mean to have changelists,

pull requests as you call them in non-Google land, that are evaluated more quickly or more readily or more readable by everyone and not just, you know, what is it, what is the cost, what is the tax on minorities who have to get up to speed on a code base where the code was written by cis men, reviewed by cis men, cis white men, and maintained by cis white men for five years, and now all of a sudden you're a black woman getting up to speed on the code base. What is the tax? How do we measure that tax? Because it's non-zero.

I think we can all be pretty confident from a number of things that there's a non-zero tax there, because people communicate differently. And Google actually has, you know, the data to start measuring that. We can do studies on, you know, productivity of women programmers that are not just like N equals 20 studies. We can do studies on, you know, queer and trans people of color who, that are not just like, that are in

equals 20 studies, you know, which is like impressive, that are not just like case studies within equals one, right? I'm very interested in understanding programming languages from an inclusivity perspective, from a, like, how can we make the future better? How can we make the next generation of programmers, how can we make programming accessible to everyone, right? How can we get programming languages to the point where it's reasonable to have it be a skill like English that's just taught in elementary schools, it's available to everyone as part of public schooling,

and, you know, you decide to go into schooling. And you decide to go into programming just like you decide to go into journalism because you know the language. It's part of your background knowledge. And the opportunity is available to everyone. And that's really what I felt like Google offered me the opportunity to do, both explicitly and implicitly. just because of the size of the

company, the number of engineers I get to work with, the number of engineers that are impacted by the library design I do there. And that's really played out in my first six months. I've done some really cool things. I've gotten to be involved in some really cool things, some of which I can talk about, some of which I can't. Everything, all of which I will hopefully eventually be able to talk about. One of the things I told Google is that I wanted to work mostly on open source. I wanted to be able to open source the things that I worked on. I wanted to be able to publish about the things I worked on.

And they said, great, that's what we want you to do. So, yeah, I'm not an evangelist for all of Google, but I definitely think my part of Google is some good people doing really good things so i'm enjoying it thank you for asking yeah that's very cool and you know as this white man i'll say you know we're starting low on time but i am curious what you know if you

have like an example of what you mean when you're talking about like writing the code to actually be inclusive i know i've heard discussions on like know, avoiding using terms like whitelist and blacklist instead use like block or something like that, or avoid using like master slave relationships, use something else that is not, you know, offensive language. Like, is that kind of what you're talking about? Or is there something else to it? So there's, there's a couple of things there, right? There's, there is inclusive languages is like the most obvious and simple thing we can do, right? It's the most explicit thing we can do. But the problem with this discussion is that when you try and come up with very specific

examples of this kind of thing, right? They all sound cheesy. Like you can come up with like hilarious examples of like why code is better because you know an app an ios app written by you know 10 white men forgot that like you know half of the world has periods every month you know things like that like random like you know ridiculous over-the-top things and they all sound cheesy and you're like well you know that sounds like a great reason to hire women and that that's that is but that's not like the point here right the point here is that it's a ton of little

micro taxes that have to do with the way that community people communicate and we saw this um more so 50 years ago less so now we saw this more so 50 years ago with uh writing writing like with books right uh the turn of the 20th century uh people were talking about and that's more than 50 years ago but uh women authors were talking about how books were not written in an accessible way to women right they were written for cis white men by cis white men um and there were a lot of women authors trying to change that, right? And there's these little microtaxes about communication styles, about ways of expressing things that are different between minorities,

between women and men. And if you don't have a team that involves um inclusive and diverse representation um then you don't get communication styles that represent everyone right and uh so it's it's really hard to describe in specific examples that's that's the hard part about talking about this right is that it really involves these micro taxesotaxes that start to add up. I try to avoid giving specific examples because that's not really what it's about in some sense. I think that having the data to actually measure that is a really interesting experiment,

but I think we should have inclusive teams and inclusive designs because that's the right thing to do, not because it makes us more money. But beyond that, it's like really interesting to be able to show companies that it also makes you more money and it makes you more productive. Right. And so I think that's an interesting experience to discuss. But yeah, no, I don't have a lot of specific examples. Obviously, using inclusive languages is the first place to start, right? But code is just a means of communication.

And regular English language or whatever language, spoken language, is a means of communicating and has the same effects that have been measured for decades, right? So it would be surprising to me if code doesn't have the same microtaxis that involve the ways that people express things. I think there's also some effects of code reviews, the way that people emotionally deal with each other.

Makes it hard for minorities and women to get up to speed on a team. I think that anyone who's been marginalized their whole life will have certain reactions to code reviews that will cost them a lot more in terms of emotional well-being that will lead to burnout a lot faster. And so I think doing all we can to minimize those things and really make programming accessible to the next generation I think is something that we need to think really hard about as people who have sort of made it in

programming. I think we have something of a duty to do that. Sorry, I soapboxed on your Simples Plus podcast about that and I knew I was going to do it because I love talking about this stuff, but I really appreciate you giving me the platform to talk about it.

Well, I think we are running out of time, but since we were on the subject, I did want to allow you to put in a plug for IncludeCBP. I think you wanted to do that. Yeah, IncludeC++ or IncludeCBP. There's a Discord server for that. It's really about inclusivity for minorities and allies in C++. Look that up.

I don't know the exact web address, but we can Google it or we can put it in the show notes. We're also trying to get up to speed and effort for women in C++, trying to get up to the point where we have 25% women attendees by 2025. We're having a women's brunch next year at CPPCon. So if you're interested in that, reach out to me on social media or in various channels. And hopefully we can start reversing the trend that we have in C++. That's really a problem. Okay, well, thank you so much for coming on the show today, Daisy.

Thank you so much for having me. I really enjoyed it. Yeah. Thanks a lot for coming on. That was great. 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.