CppCast - Memory Algorithm Proposal

Episode Date: January 5, 2017

Rob and Jason are joined by Brittany Friedman to talk about her accepted C++17 proposal which adds new algorithms and utilities for memory management and the process she went through getting the proposal accepted. Brittany Friedman is a dense collection of matter formed from molecules originating from inside the sun. She currently works as a programmer at Gearbox Software, where she weaves ones and zeroes into intricate little patterns. Her proposal for new memory management algorithms was accepted for C++17 and a bug that she filed against the C++ standard was fixed the way that she recommended. So basically you do not want to trifle with her. News 2016 Software Developer Podcast Awards Keep Disabling Exceptions C++17 Why it's better than you might think A new way of blogging about C++ Brittany Friedman @listenserver Brittany Friedman's GitHub Links Extending memory management tools drpdb: Convert from Microsoft PDB format into a MySQL database Symbol Sort: A Utility for Measuring C++ Code Bloat Gearbox Software CppCon 2016: Nicholas Ormrod "The strange details of std::string at Facebook" Sponsor JetBrains

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. Episode 84 of CppCast with guest Brittany Friedman recorded January 4th, 2017. In this episode, we take a look at a new tool for C++ bloggers. Then we talk to Brittany Friedman from Gearbox Software. Brittany talks to us only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Good. Had a busy holiday. How about you?

Same here. Traveled up to new jersey and back like i mentioned before had a pretty good time saw a family that's right you were looking forward to christmas in new jersey oh yeah you had a good holiday though yes i did that's good well at the top of our episode i'd like to read a piece of feedback uh this week uh daniel writes in from germany saying first of all love the show great work keep it up and i have a small feedback for show number 81 with nicholas flurry you discuss string implementations and avoiding the heap by using and even extending small string optimization i recently published a small library that has a stack only heap free

string implementation which basically is a standard string-like interface around an ordinary character array. It can be useful for optimizations and migrating legacy C code. You can find it and it has a link here, which I'll put in the show notes. And if any of you or Nicholas have any use for it, cheers and thanks a lot for the show.

So yeah, we talked a bit about string optimization based on one of the talks that we all watched at CppCon. Yes, that's right. That's a really good talk. It is a very good talk, and it's a short one. It was only, I think, a 25-minute talk, right? Something like that. It was after our talk, so it couldn't have been more than an hour or more than a half hour.

Right, right. So yeah, always good to look at these small optimizations. I know they can really help. Everyone's using lots of strings interesting about that kind of thing a small stack based character array string implementation could be made fully constexpr I don't know if that implementation is and there's some very interesting possibilities there

assuming it cannot grow beyond the fixed array size. Okay. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us reviews on iTunes. Joining us today is Brittany Friedman. Brittany is a dense collection of matter formed from molecules originating inside the sun. She currently works as a programmer at Gearbox Software, where she weaves ones and zeros into intricate little patterns. Her proposal for new memory management algorithms was accepted for C++17, and a bug that she filed against the C++ standard was fixed the way that she recommended. So basically, you do not want to trifle with her. Brittany, welcome to the show.

Hey, guys. So, okay, what was the bug fix that you got in the standard? Yeah, okay. So the part of the standard that I was working in for my proposal, you know, I was just working along in it. And I happened to notice something really weird, which was a standard address of it's a handy little function for taking the address of an object. I noticed that you could pass an R value into it, and it would be totally okay with it. So you could pass a temporary object into address of, and it would take the address of it. Huh.

And that's kind of a problem, because you should not be able to take the address of a temporary. Yeah. Yeah. So, yeah, that was my bug. And my recommendation was to add another template, basically an overload, that would be deleted if it was an R value reference. Interesting. Yeah. Oh, okay. So nothing too crazy, but something that kind of flew under the radar for half a decade.

Yeah. So pretty good, pretty good. A little change. I think that's amazing. How many of these tiny little things are going into C plus plus 17? That would be nearly impossible to keep track of all of them. Oh yeah,

absolutely. There's just, there's a lot of people working on it and there's so many little edits. Um, you know, you, you tend to get a lot more with any standard than you realize anyone reports not necessarily especially in the realm of bug reports right okay well britney we

have a couple articles to discuss feel free to jump in on any of these and then we're going to start talking to you about some of your other standards work and some of the work you're doing at gearbox okay yeah okay so this first one, we actually talked about this last week too, Jason. And this was about the podcast awards, the Software Developer Podcast Awards. And we were kind of joking about it last week because we were and are the only podcast

in the C++ category. So they had these category by category uh votes and we did of course win for c++ yes podcast yeah congratulations um so what they're doing now though is they took all the category winners and they're now holding a second vote for best overall podcast and last week we kind of jokingly said we had some stiff competition. This week we really do have stiff competition. I'm not really expecting a win on this one because some of these podcasts have been along for quite a while.

But we'd still appreciate if our listeners would get onto the website and vote if they're interested. Yeah, vote early, vote often often as they say right yeah exactly but yeah some of the podcasts were up against um i know i've heard of before dot net rocks i think they were around before podcasting was called podcasting oh goodness pretty impressive i think they've been around for like 12 years or something that's older than you are right rob no no it's not although i guess i was in school then wasn't programming professionally or anything then yeah sorry i couldn't resist it's okay well let's uh get on to the other articles uh the first one is keep disabling exceptions and this is an article from sean middle ditch

and i'm guessing you probably have some comments on this one britney oh yeah definitely Keep disabling exceptions. And this is an article from Sean Middleditch. And I'm guessing you probably have some comments on this one, Brittany. Oh, yeah, definitely. I work pretty closely. Well, I work a lot with Sean in SG14. So, yeah, we talk a lot about this kind of thing. Yeah, and this was a response to someone else writing an article saying to stop using F no exceptions. And yeah, he obviously disagrees with that person's perspective on it. Yeah. We might be jumping a little ahead of ourselves here. But you do game development. Do you compile with exceptions on or not?

So I think there's an important distinction to make here. The distinction is, do you use exceptions? And do you compile without compiler support for exceptions? Right. And those are sort of different because if you use the standard library, they throw exceptions in all sorts of places. And some compilers are not very happy if they see a throw statement when you're compiling with throwing disabled um so i've never worked on a project that used exceptions extensively uh that doesn't mean we always disable exceptions uh for example the xbox uh xbox one uh as i recall it uses exceptions pretty heavily in some of their code. Yeah.

As part of Microsoft's deal, which may be inherited from an RT, I don't know. But yeah, so... But we avoid it in as much code as we can. And I generally agree with that. They're really a problem. In particular, at least the reason I don't like exceptions, if you robustly support exceptions, if you're going to try to provide exception guarantees, like a basic or a strong exception guarantee,

you basically have to look over every single line of code in your program and say, what if an exception is thrown here? Right. At least if you're writing generic code, right? If you don't know exactly what's going to happen if you're calling random function x and function x might might throw because it's customizable um that's that's so much brain overhead for me maybe i'm just not smart enough but uh that's that's like so much to have to deal with um and then there's a documentation problem of saying these are the exception guarantees.

These are when you're allowed to throw. It's really hard. It's really hard. It's so much easier just to say, no thanks, we're passing on exceptions. And that's the sense that I sort of agree with this. Yeah, that makes some sense. One of my favorite C++17 features that's coming up is the no discard. What do you call that?

Attribute? Attribute. Thank you. Yeah, that's the one. Just went right past my mind right there. The no discard attribute, which he mentions in this article. And I think that can go a long way to reducing the use of exceptions where we want to say you cannot ignore this error. Well, now there's a way to say an attribute.

Now you can't ignore the error. Yeah, definitely. It'll help us write better APIs. And better APIs may reduce our dependency on exceptions in some ways. Right. Okay. right okay uh this next one is an article written from um our recent guest uh whose name i just blanked on for a moment phil nash phil nash and he's writing c++ 17 why it's better than you might think and what was your take on this one jason is basically he mentioned the uh the article we talked a little bit about lat or two weeks ago about uh the c++

standards meeting and he's kind of going over how maybe it's not such a bad thing if you know modules and coroutines and ranges didn't make it into c++ 17 just because we're kind of still adjusting to c++ 11 in a lot of ways as a community. Yeah. I mean, I agreed with the article because, you know, I mean, we're getting caught up in the, like, well, these big features that we were hoping in C++17 didn't make it. Right.

Coroutines, modules, and concepts are, like, the ones that people want to talk about. But all of these little things that Phil mentions, constexprf, destructuring, or structured bindings, whatever you want to call that, I think they're going to add up to changing the way we program in C++. And, you know, it's something I've been playing with lately. And I think I agree with him. I think there's enough here that it's going to keep people busy for a couple of years, basically. Right. How about you, Brittany? What are your

thoughts on this as someone who got a proposal into C++17? Well, okay, so there's a lot of people who are expecting c plus plus 17 to be a so-called major release yeah this this sort of model where we have major and minor releases of c plus plus oh three was minor 11 was major and if you follow that sort of cadence 14 would be minor and 17 would be major right it's a there's sort of a natural expectation there that uh c++ 17 should be huge um that's completely the wrong way to think about this at this point we're no longer working in the realm of major releases and minor releases um it's it's more of an agile methodology i think at this point um right every some number of years they, they're targeting three years, every three years, they'll release a standard. If your favorite feature doesn't make it, then maybe it'll make it next time. But the I think the intent here is, is going to be good for C++ in the long run. It just means that there's a problem of expectation management. And I don't I don't want to say anything about Jarnus Stroustrup. He's a great guy, but he did write that post that said all the great things,

the 10 great things I want in C++17. I think his intent there, I can't speak for him, I think his intent was to sort of push the committee in a direction and encourage them and focus the committee toward, you know, some, some goals. But a lot of people saw that and saw it as a promise. Yeah. And that, that was really a problem. So I don't consider this his fault by any means. So let's keep in mind, wasn't that article just intended for the committee members and it kind of got leaked out and everyone caught wind of it right i think so

yeah um it's hard to write anything i mean look at last year you can't write anything on the internet without everyone seeing it that's true um but uh yeah i think i think there's sort of a problem in c++ just of expectation management of public relations yeah um that's sort of a role that herb sutter has has fulfilled for years and years and years for c++ we probably need more voices in the who are in the committee uh making an effort to really uh shine a light and communicate the things that are happening and communicate proper expectations um You want to do that? Yeah. Maybe we're doing our small part.

I don't know. Okay. I think you are doing a pretty good, having a pretty good role here. But yeah, it's a hard problem. But I think it's way more useful to talk about, I wanted feature X and I'm disappointed, as opposed to C++17 is small and I'm disappointed as opposed to C plus plus 17 is small and I'm disappointed.

Yeah. Um, so if, if there's particular features you want to be in the standard, um, all I can say is either have patience or try to make an effort to help out. And there's so many ways you can help out, help out with implementing the feature,

help out just editing, like contact the person writing the proposal and say you're willing to edit for them. There's tons of things that can be done. But it's certainly easier to complain. And it's easier for the committee to focus on, you know, them trying to get the proposals out as opposed to bring new people into the fold that can help.

There's only so much any of us can do. We're all just volunteers. So it's a tough problem, but I think communication will be really key to at least improving attitudes across the board. Right, right. Okay, this next article is a new way of blogging about C++.

I thought this was pretty cool. This is a JavaScript plugin that you can include in any HTML blog website. It basically allows you to write a snippet of code in C++

and have it so that code is evaluated and you know the results of it are displayed in the blog and the really cool thing is you can make edits to it and it'll immediately re-evaluate the code yeah it runs really quick that's for sure yeah I was playing with the F fibonacci generator here and just changing the a number of uh you know the number of fibonacci it counted up to and it uh you know re-evaluated it pretty quickly yeah it's pretty cool um i i at least one thing that that sort of annoyed me about it was that there was didn't seem to be a reset or a way to compare. So you change all the code and you can't really go back, at least without refreshing the page.

And I think about this. We have Godbolt, his online compiler, which is incredible. And it shows you the assembly, which is incredibly useful, but it doesn't execute. At least, I don't think it executes the results in real time. This is sort of the opposite. So I mean, ultimately, where's this headed? Where's the sort of technology headed? I think we want like, a plugin, a Firefox plugin, or a Chrome plugin, which is just Visual Studio, just sitting there inside your web browser. But I'm serious.

Ideally, if we're going to have this feature, which I think is really cool, I think it's really cool. One thing I'd really want here is the ability to set a breakpoint. Because the whole point of this is you're testing out something maybe you don't understand. This is a new feature. You want to play with it a little. And breakpoints are sort of how you play with code. So that would be a real big thing here. And eventually we're talking about re-implementing a full-featured compiler front-end, back-end, the whole nine yards. So maybe, I don't know. know i don't know i'm just talking out loud but why don't we just recompile uh jeep cc or clang with in script done and run in the browser well yeah i was thinking about that with web assembly we're going to be able to put all the compilers into the browser if we want to right that'd be so huge so huge. Yeah. Correct me, please, if I'm wrong here, but on this C++ page we're talking about,

I don't actually see a single feature of C++ that it supports except for CL. Yeah, and actually... Like, if you type class, it fails to compile. He mentions at the bottom that it's a partial implementation of C++. So I didn't realize

it couldn't do classes. That's pretty partial. Yeah, I looked at what features are implemented. Operators, primitive types, variables, arrays, pointers, if-else, switch, for, while, do, functions, variables, and preprocessor directives. operators primitive types variables arrays pointers if else switch for wild do functions

variables and pre-processor directives so it's really more like c yeah it's really more of a c but it's still cool yeah it's still cool it's very cool i definitely had the same thought as soon as i saw it i was wondering if uh we could get godbolt into the into a blog post the same way that this did it. Yeah, as I understand, that project's open source, the Godbolt compiler is open source. So if someone was willing to put in a little elbow grease, I bet you could make an equivalent sort of little embedded feature in your blog.

Well, he does have an embedded one that you can show the source and the assembly output, but not the execution of the program. Sure. Does that do live changes or do you need to go back to the compiler explorer website to make changes to no it's actually live i suggested to him that he might want to do like a screenshot or something just reduce server overload but yeah very cool okay well britney let's start talking uh let's start off by asking a little bit about the game development work. You said you work at Gearbox Software, right? Yeah.

So what games have you worked on there? Okay, so yeah, I joined Gearbox about seven years ago, which is a pretty long time to be at the same company, especially in the game industry. Yeah. company especially in the game industry yeah i joined the company uh to start work on borderlands 2 they hired me to help make borderlands 2 possible and uh since then you know we've had all sorts of dlc or as they used to be called expansion packs um uh for borderlands 2 and we made the pre-sequel and all of its dlc and I also worked on Battleborn. So it's a pretty good chunk of stuff I've had there. And we've released other things in that amount of time, but those are the only projects that I've directly had

sort of my hands get dirty in. And it's been great. It's been really fun. I don't think I've heard of Battleborn. I see it now on the website. Uh-huh. Yeah. I don't think I've heard of Battleborn I see it now on the website uh huh yeah Battleborn is maybe not as

the diplomatic way to put it would be it's not as well known as some of our other I'm definitely familiar with Borderlands although I don't think I've played through the entire game you definitely should I would highly recommend it we get some profit

sharing here at gearbox so oh really it's my it's my duty to uh encourage you to purchase in fact you should get multiple copies really i would you know that leads right into the next thing i wanted to talk about is you know what's the culture like from your perspective working in the games industry it sounds like if you get some profit sharing, it's already sounds better than some of the horror stories I've heard. Well, Gearbox is very peculiar, and that we get profit sharing. That's, that's pretty much unheard of in the game industry. It's a very special feature that we have. So yeah, I mean, mean overall the game industry has been really interesting in some sense it's really hard for me to compare with what other interest industries have because

this is the only industry i've worked in right so you know if this is all you know it's hard to say if it's good or bad it's just all you know but um you know from my understanding, it's not entirely dissimilar from a normal, quote-unquote, software project, but there's definitely some peculiarities. We've got around 250 to 300 people employed at our company. Wow. That sounds pretty good. Yeah, it's considered medium size in the game industry. Okay. A big company would be a thousand people working on one game at a time. Wow.

Yeah, I know. And we have, I mean, the numbers I'm giving are pretty rough, but I believe we have around a hundred artists, including animators, 3D modelers texturers um people who focus just on lighting a scene to make it look good wow um we have somewhere around 30 or 40 programmers so in that sense it's maybe more reasonable if you're only thinking about the programmer side. But it can be, it's, it can still be really tough, because, you know, I make a change to our source code that prevents artists from being able to do work, which is so easy to do. It's incredibly easy. Oh, yeah, you're going to be really popular.

Or God forbid you cause them to lose their work, whether it be a crash or you serialize information incorrectly. You're going to have a lot of people unhappy with you, a lot of money that can get lost very quickly. Do you want to tell us a little bit more about what exactly your role is at Gearbox? Yeah. For most of my time at Gearbox, I've been a tools lead, which is probably the worst position to be in as far as this discussion we're having. I was basically the point of contact for whenever the artists weren't able to get work done, more or less.

So yeah, tools in the game industry, at least at Gearbox, is talking about the art pipeline. So how do we get art assets into the game? How do we build stuff inside the game? How do designers specify how much damage a gun does or how does a designer specify the AI behaviors of this new monkey enemy we're making or what have you.

And it's incredibly detailed. So many different pieces to game development, vehicles, at least to our games. So many pieces. Missions, vehicles, the projectiles that fly through the air the skills the players uh the worlds so many different things um incredibly diverse really interesting it's also really stressful you can imagine with so many people depending on you with um you know looming deadlines all the time um yeah Yeah, it's never a dull moment, I guess would be the right word, right?

Sure. Yeah, it's really special. And it's sort of from that situation that you get crunch. It's from something went wrong and you lost a day of work. It's from I don't want to check anything in this week or I don't want to check this change in this week because it's kind of work. It's from, I don't want to check anything in this week, or I don't want to check this change in this week, because it's kind of dangerous. So I'm going to check it in over the weekend. Right. And you're, you know, that totally makes sense, because no one's working on the weekend, or very few people are, you're minimizing the risk. So I've never had someone come to me and say, Hey, you have to work this

weekend. I've never had someone say, sorry, you got to put in 60 hours this week. It's on my budget. You just have to do it. But deadlines can get really strict. I once had a deadline that was this needs to be done by 9am Monday morning monday morning which is pretty much telling you to work on the weekend right um and you were told at 4 p.m on friday it wasn't that bad no i had i had um uh proxim i had a few weeks notice ahead of time um but uh yeah it's tough it's tough and it can be really stressful. And this peculiar feature of Gearbox that I spoke about where we get profit sharing, that can encourage you to crunch a little bit more.

Right. Because if the game does well, you're going to feel it in your bank account. So in some sense, that can make all of it a little bit more worth it. It might also encourage at least certain personalities to work a little bit more than they would otherwise. Right, right. But it's going to be different everywhere. And it can vary a lot. Sometimes your deadlines are directly tied to company profits based on how the contracts are laid out between you, your game studio, and the publisher. I can't say anything about Gearbox's profit model here.

Why don't you want to publish games right before Christmas and that sort of thing? There's definitely that. There's also, or you don't want to release a game too close to a competitor's game there's also a situation where uh the contract may specify that you know the company gets money based on making its milestones and so if you fail to meet your milestone you might get less money from the publisher or they might just drop your money that milestone sorry try again next milestone and maybe we'll pay you. Totally depending on the contract situation. So yeah, there can be a lot riding on this in ways that maybe are not as common

in other fields of software, but I don't know. I don't really know how. I've never been in another industry, so maybe all companies are like this. But I get a feeling like it's a little bit different in the game industry. I'd like to interrupt the discussion for just a moment to bring you a word from our sponsors.

C-Line is a cross-platform IDE for C and C++ from JetBrains. It relies on the well-known CMake build system and offers lots of goodies and smartness that can make your life a lot easier. C-Line natively supports C and C++, including C++11 standard, libc++, and boost. You can instantly navigate to a symbol's declaration or usages too. And whenever you use CLion's code refactorings, you can be sure your changes are applied safely throughout the whole code base. Perform unit testing with ease as CLion integrates with Google Test,

one of the most popular C++ testing frameworks, and install one of the dozens of plugins like Vim Emulation Mode or Go Language Support. Download the trial version and learn more at jb.gg slash cppcast dash C-Line. So you said you work on the tools and how assets get into the game, and you mentioned just briefly, like, and like specifying things like how much damage does a gun do or whatever. I'm really curious, how actually do you specify those things?

What solutions have you come up with scripting or whatever, if you can talk about it? Oh, yeah, definitely. So that was pretty much what I did at Gearbox for pretty much the entire time I've been here. So the way that it was done at one point before I joined the company was basically we have an editor, a large editor with 3D viewports and has all the assets listed and that sort of thing. Until recently, we've used Unreal 3 3 the game engine unreal 3 um but you know these game engines aren't built for making our game they're built for making you know their generic platform for game development so you know you buy a game engine it's not going to have here's where you make character skills and here's where you specify how much damage the gun does.

A lot of that stuff has to be built on your own because it's sort of a generic foundation you're building on. So before I joined the company, it was basically spreadsheets, was how it was done. We had spreadsheets inside the editor, and, you know, a designer would find the appropriate cell in a spreadsheet and type in the number and then play the game and see if they like it more than they liked it before. Huh.

Which is, you know, spreadsheets are incredibly powerful. You can do anything with a spreadsheet. But, you know, it has limitations once you reach a certain level of complexity. So yeah, most of what I did at Gearbox was developing visual scripting languages for all these different things. So for example, we had AI programmers who were focused on how do we get AI to animate smoothly and react to threats and that sort of thing.

But when it came to sort of the integration with designers, I would be making a visual scripting language, or at least helping the AI team make a visual scripting language to define, you know, a very domain specific language for this is how AI works in our game, used behavior trees um so so you know we built a specific scripting language just for describing how enemies act and then we built another scripting language for designers to specify the structure of a quest in our game and then we built another domain specific language for uh general scripting purposes. That's interesting.

So you've developed multiple domain-specific scripting languages instead of using something more common like Lua? Yeah, because there's a couple of pieces here. At least our designers don't have, very, very few of them have any programming background whatsoever. In fact, if you ask them to open up a text editor, they will freak out. They don't like it. So, yeah, we needed something visual. And, you know, maybe we could have tried to build like a visual scripting language on top of Lua, maybe, for example. But almost all of our needs are domain specific. Lua is not great for describing a behavior tree. Because these are sort of very specific data structures that we're building. So, you know, we've got this, this rich, robust UI that we can add arbitrary complexity to. And in the back end, where the game actually runs, we have a specific

data structure that the AI team wants filled in. And that's, that's sort of, we essentially have a compiler, which converts this visual scripting language into the data structure that the AI team built. And they need this because the AI team wants to be able to say, okay, here's our behavior tree. I need to know what's going to happen, you know, three nodes down, or what's going to happen if I take this branch, they want to be able to sort of analyze the data to get get useful information out of it. And if it's just arbitrary source code, that's really hard. It's really hard. If you just have a Lua function and you want to know some intricate detail of what's going

to happen if I call this function, that's a really hard problem. If you make a specific data structure, that's really easy. Just read the float or what have you. So yeah, so that was sort of our motivation for all of this. And it was really successful. At least if you look at how much content there is in Borderlands 2 versus Borderlands 1, that will more or less be a testament to how well this idea went. So I think it was good. So the ease... Oh, sorry, go ahead.

No, go ahead. Uh, I was just going to say the easier the tools are that you create, the more content your designers are going to be able to get into the game. 100%, 100%. And, and something that's a little bit weird about being in tools is no one else can get work done until the tools are ready. Right. Right. are ready. Right? Right, no stress.

Right. You can't write a novel if Word doesn't load. Right? And that's effectively what my role is. I'm making Word so that the designers and the artists can make the novel. So I had a tendency to crunch more at the beginning of a project to get everything ready to go as opposed to crunching at the end of the project, though I would often end up crunching at the end of the project too,

for other reasons. But my, the bulk of my work was front loaded and so that other people could actually finish, could get started making the game. So do you want to tell us a little bit about the proposal you got in for C++17? We already talked a bit about the bug fix,

but how about the larger proposal? Sure. It's not really a large proposal, but I'm proud of it, so that's what matters. Yeah, so one of the things I've done at Gear so like i said i was the tools lead and at least the structure of the engine we used it meant that the more you know about the tools the more you know about the game because they were a shared code base okay it was all just one giant code base that had the editor and the game run time altogether. So as things go wrong, wrong in the tools,

I would end up learning things incidentally about the low level game systems and the low level engine, just because there is all shared. So I, you know, I, I ended up sort of a little bit transitioning from pure tools to also doing low level engine work. And it was through that that I started looking at some of the containers that we wrote, our version of standard vector, and trying to improve them, make them a little more efficient, that sort of thing.

And I noticed we had some algorithms in here that were very similar to or some functions that were prime for being made into something like a standard library algorithm. So I sort of separated those out, made them nice little algorithms on their own right, and then did some research and found like these are used everywhere. These are really commonly needed, especially for people implementing containers. So for example, in our vector class, one of the things you need to do in a vector is default or value initialize the objects. So you construct the container,

and then you want to fill it with 100 value initialized objects. Okay. That's a loop from beginning to end, where you do something to each element. And it's an algorithm. So that was that was one of the algorithms that that I identified as being useful. And that I identified as like tons of other companies were using by, you know, some other name name often not a separate function just you know incidental in the middle of their code so i said you know these probably be worth worthwhile standardizing because they're very similar to some existing algorithms that were in the standard

so i said why not why not see if uh if the committee would like these so i so we got an uninitialized move for moving objects move constructing objects into a range of uninitialized memory uh uh uh we have standard uh what's their uninitialized value construct uh and that's for value initializing objects. Uninitialize default construct for default constructing. And destroy for destroying a range. That would be your vector destructor. Destroy all the objects in the vector. And destroy at, which just calls a destructor on a single object.

So yeah, that was sort of the motivation. I ended up finding a lot of, you know, I ended up rationalizing a lot of good reasons for it to exist and finding all sorts of examples of this stuff on GitHub, wrote a proposal, found its way in somehow. So yeah, it was a great, great experience, definitely. And hopefully, hopefully it was, you know, for the good of C++ as a whole. I think it was. So you're not actually, are you on the committee? Well, that's a really interesting question. It's not entirely clear to me what it means for someone to be on the committee. What I think it means for someone to be on the committee is that that you are part of the like registered iso

bigwigs like a very there's that's a very formal process right and it means you have voting rights as far as what actually makes it the final step in the process so no in that sense i'm not a member of the committee i'm someone who showed up at one of the committee meetings and strong-armed them into accepting my proposal so that was your first one of the committee meetings and strong-armed them into accepting my proposal. So that was your first experience with the committee then, I take it? In person, absolutely. I'd met some of the people involved, or some of the people at least that helped me. I'd met at CppCon.

You should definitely go to CppCon for anyone who hasn't been. So that sort of networking helped me get the process started. And some of the people in SG14 that I work with in that regard were instrumental in helping that process along. But yeah, when I actually ended up flying to Finland, that was my first interaction with the committee. Yeah. Were you already involved with SG14 at the time that you discovered

all these algorithms in your code base or did that prompt you to look into sg14 no i was already starting um starting the the process sg14 hadn't really got off the ground a whole lot okay uh at that point but yeah i was i was right there from the beginning um and i we were actually having a discussion on the sg14 mailing list though that the technical term for mailing list is reflector by the way uh the sg14 reflector i know right and what we still don't have reflection so i know well we actually have a reflection reflector, I think. So we're on our way there. Yeah, so on that mailing list, we were discussing, you know,

we often use optimized containers in games industry, ones that don't throw exceptions, ones that maybe can do default initialization instead of value initialization, maybe use a different allocator model, all sorts of things that we do differently, often with our vector, just tiny tweaks, but they can make a big difference. So we were discussing the ideas about maybe proposing new containers. And I said, well, how about we start off with proposing pieces that can help other people implement containers. So instead of making these huge controversial decisions

about new allocator models and never throwing exceptions, that kind of thing, like the kind of stuff no one wants to debate because it'll go nowhere. It's much easier to provide these little library pieces to help us and other people, library implementers, you know, make their lives a little easier when they are making these specialized containers, at least make the process easier, less error prone. So that was sort of where that sort of originated from. And my experience with SG14 was great.

My experience with the committee was generally good. Yeah. Well, that kind of leads into another question we had. What was the process like getting your proposal accepted? Did it take multiple revisions? Yeah, it's not an easy process. Okay. I may ramble a little bit, so feel free to stop me because this is an arduous process. And I can go through it step by step if you really want to, or I can try to give you the abbreviated version. But I suspect maybe some people would be interested in knowing the full rigmarole. Okay, so you start off the process with thinking about it.

That's usually a good starting point, thinking about your proposal. And once you've got a good sort of baseline, a good foundation for your idea, there's a reflector, a mailing list, called STD proposals. And that's where you're supposed to start off a topic, talking about, hey, I've got this idea. From there, you'll get feedback. People will say it's a terrible idea. Mailing list tends to be a little

negative. Be strong. My proposal was really simple, so it didn't get that much blowback. But yeah, you'll propose it there. You'll get feedback. Alternative implementation ideas. People saying it's not worthwhile. People saying we really need this, what have you.

Ideally, you'll incorporate all that feedback into writing a proper document that is formatted according to ISO rules and fully presents your idea in the way that they like. So once you've got a paper that you feel like is ready, I want someone important to look at this, then there's an email address you'll submit it to, and that person will take the document and include it in the next official mailing. There's like a bulk mailing of all of these C++ proposals that happens, I believe, quarterly.

So, and I don't know if that's really a necessary part of the process, but the more of these steps you follow, the better of a chance you have of getting it in. So that will get a lot more eyes on your proposal if it's in this official mailing. From this point,

you're doing good. You're about 10% of the way there now. I know, right? So your next step is to get people at the standard committee talking about your proposal. So either you need someone to actually attend these meetings in person to so-called champion your paper. This could be yourself.

If you or your employer are willing to put up the money for you to travel to Oulu or Hawaii or wherever it's being held. Chicago, I think, was the most recent one. They hold it all over the world because this is an international standard, and it would be very unfair if it was held in Nebraska every year because then the people in China would have real trouble making it. So they change it all the time. So you make it to the committee meeting, and using your advanced social skills,

you will convince them to schedule it. Because they actually need to talk about it, and there is a schedule. So you'll convince the appropriate committee or subcommittee that it needs to be talked about. Now, this is where we get into the structure of the committee, which is really important because you don't want to have your proposal sent to the wrong committee. And then they're like, sorry, come back next year. So the standard committee is sort of broken up into two branches. There's the people focused on the library and the people focused on the core language. And each of those two branches is split into an evolution side and a implementation side, you might say.

So, for example, there's evolution and core, which are focused on the language, and there's library evolution and library. They work on on library proposals. So were you under library evolution, I guess? Yes. So the way that works is, yeah, it was under under library evolution, I guess? Yes. Okay. So the way that works is, yeah, it was under the library branch, if you will. And your proposal starts out at evolution. If it makes it through the evolution committee, then it goes to the library committee.

Oh, okay. If it makes it through that, then there's more steps along the way. But you'll see, yeah. So there's sort of a two-phase process. The idea being the evolution committee will decide if your proposal is worthwhile, if it's the right shape, if it needs to be rethought, or if they've just got general feedback. The idea is to sort of like a high- high granularity filter or low granularity filter for filtering out all the cruft. Right?

Try to get things in a reasonably good state to pass on to the next phase. So once you make it through there, and they'll decide things like the right name to give to your functions, you know, what sort of exception guarantees will typically be decided there.

They'll get all the high level stuff usually. In the next committee, they'll decide all the low level stuff. What's the correct wording to make it into the standard? And this can be a really tough process. They'll decide, is this even implementable? Maybe it's not. Because at least in evolution, there's all sorts of people in evolution. But when you reach core or library, you're locking eyes with the people who have to implement your feature. Right. Compiler writers. Compiler writers, standard library implementers, they're going to be there and they're going to they're going to furrow their brows at you if you uh if your proposal has got some problems so uh hopefully you make it through all that process for me um i went through four i believe four revisions of my proposal and uh most of those were sort of like internal revisions that that weren't like seen by a

committee but uh so what ended up happening for me was i had a champion go to i believe it was in hawaii to get my paper through evolution And then it was at the next committee meeting that I attended where it went through library. So it was a two, two meeting process. Okay. It's, and that's,

that's almost ideal. Yeah. It's very rarely going to make it all the way through in one go. That's, that would pretty much be unheard of, um, which can be, you know,

a bit of a problem if you're self-funding and you have to attend three or five committee meetings to get your paper through. It's not great. But, you know, for as much criticism and negativity as you might hear there, I totally understand why they have this process. It makes sense. There's only so many people in the process so i'm not i'm not um criticizing the committee they're they're great people and they're doing great things but it's it is a little bit like going through a meat grinder uh at least definitely for someone who's new to the process sure it was it was hard um anyways you've made it all the way through through this subcommittee um you're still not quite done.

So the subcommittee, like the library committee or the core language committee, have decided, okay, we want your feature, and we also want all these other features. And then at the end of the meeting, they say, okay, guys, here's all the features and bug fixes that we've decided we want for the next draft of the standard. They'll go through them one by one and say, we want uninitialized memory algorithms.

Anyone want to vote against it? And this will be everyone who attended the committee, people from all sorts of backgrounds. You'll have members from national bodies. So the guy representing Czechoslovakia for C++ will be there and he'll have a chance to vote against it. The people representing Google and Apple will be there with a chance to vote for or against. And the goal there is to achieve consensus consensus i don't think has a very strict definition uh so at my my approximate guess would be around two-thirds counts as consensus so if about two-thirds of people vote in favor of your proposal then it's in sweet

uh yeah so that's that's more or less the process there can be a little bit extra there might be merge conflicts um and uh the editor of the standard will help you with those merge conflicts uh it's and there after that there can be bug reports filed from national bodies saying you know we really hate this feature, or we, we will vote against the feature unless you accept these changes that we propose. That that can happen. And then finally, at the very end of the process, all of the most important stakeholders from the various national bodies get together and make a final vote. This will be the next version of C++. And that is how an idea becomes a standard. So how important was it for you to have an implementation

ready to prove to the implementers that this was possible and useful? Yeah, I think they're becoming really strict about that. Unless...here's the thing thing if your idea is really simple then you should be able to implement it very easily right like mine mine was just a couple of functions no big deal to implement you could you know writing the functions was like 15 minutes and getting it into the standard was weeks of my life um So, you know, if you're writing a simple proposal, you know, that's almost without asking, you should definitely do it. But on the other hand, if your proposal is really complicated, you also have a high burden of proof, and you also need a

good implementation because there's more risk with something that's complicated there was a time when maybe they weren't so strict about this and that's how we got export templates so they really they're really afraid of of ending up of putting something in the standard that can't be implemented or that has unexpected consequences and side effects that's happened a number of times something almost made it into the standard and they realized hey if we put this in it will screw up all this other stuff we're working on and we they just realized that at the last minute um that can that can be real danger so implementations are super important uh they're getting more and more um strict about that i think and it's one of the bottlenecks in a lot of ways that you know if we had seven or eight implementations of co-routines

we probably would have had it years ago but uh you know they they need good proof they want basically the the standard committee wants to play with your feature to make sure that it behaves in a reasonable way. They want to be able to put breakpoints in it and see the performance and the code gen. All that stuff, you need an implementation for it. So it's huge. It makes sense. Yeah. It's a huge burden, too, though.

Yeah. And it means things get delayed because, you know, we could have put modules in five years ago, but without an implementation, you're undertaking a huge risk. So I guess if you could give like one piece of advice to someone who's hoping to get something in the standard, what would you say? Make friends. Okay. Yeah, having as many friends in the committee as you can is important because unless you're part of the committee, you're probably not going to be able to attend every single committee meeting where they might discuss your proposal. If you're not there, they might not schedule it to be discussed,

or if there's no one there to defend it. Right. They may not, you know, have a lot to talk about. So if you can have champions there to help you, if you can make friends within the committee, so they'll, they'll be a little bit more accepting of your personality quirks.

Maybe you won't offend people as much if your friend is friends with them. And the whole process will go a lot smoother so you know i as programmers we like to think that we're immune to uh you know social whimsies and emotions but when you put so many people in one room or in a few rooms it's it's important to have have some friends and some social skills to help guide you through the process because especially if you're new you're not going to know what the heck's going on. So that would be my recommendation. All right. Okay.

But before we let you go, I know when we were talking earlier, you mentioned you had this project to convert Microsoft PDB into SQL. Do you want to tell us a little bit about what that is? Yeah. So this is a fun little project, sort of side thing I've worked on. So the way this worked was there was a blog post I saw a few years ago for a project made by Adrian Stone, and I'll give you guys links for this. This is a project called Symbol Sort.

And what it does is sorts all of your functions according to size. So you can see what are the largest functions in my program according to bytes of executable code. That's pretty cool. Yeah. It's really cool. And it's got a number of uses. You know, there's just sort of the optimization thing. Like maybe if your hot functions are listed as the biggest ones, you've probably got a number of uses. There's just sort of the optimization thing. Maybe if your hot functions are listed as the biggest ones,

you've probably got a problem. Or if you've got one function that's like a total outlier, it's like 10 megabytes and all the others are half a kilobyte. It's worth looking at. It's definitely worth thinking about. But it can also have a huge effect on compile time because those huge functions can take forever to compile. Often the biggest functions are going to be auto-generated with macros, X macros, or some system like that.

And you don't realize that you have a huge function because it's all hidden behind abstractions of preprocessor stuff. So this can sort of reveal that hidden cost that might otherwise not be available to just looking at the source code. So this was a really cool project, and I sort of looked at how it was implemented and was really interested in it. He's using an API, Adrian.

I think Adrian's he. I don't know, actually. The implementer of this program made a really cool thing, and it was using Microsoft's DIA API, the Debug Information Access API, which has access to pretty much everything that the debugger has access to. In fact, I think the debugger is implemented using DIA. So I realize there's tons of data that he's just throwing on the floor. He's just grabbing the functions and the size of the function, but there's so much more information available to the linker, which is effectively what the PDB is. It's all the linker information, all the information generated by the linker about your class hierarchies about your virtual function tables it has information of course about all your functions but at least for the pdb format it goes as detailed as hey this function calls long jump because that affects the linkage or how the linker like prologue i guess uh it so you can say uh there's there's so much information in here and i wanted access to it.

I'm like, hey, this is really cool. So my idea was, hey, let's take this PDB format, which is really hard to get information out of, and stick it in MySQL database. So then you can just perform arbitrary queries. Adrian's program here lets you sort all functions by size. That's a very simple SQL query. Select all functions, order by size, right? But now you can do a whole bunch of other stuff. Like you can say, find all data types that are bigger than this size.

Find all data types that have more than 100 entries in their V table. Select all data types and then use that to form a graph. That's an example I have on my page, on my GitHub page, is I took the output from my database and used it to generate a graph, an inheritance graph of my entire program. That's pretty cool. Yeah, there's a lot of cool stuff you can do with this. It's very similar in a way to Clang tooling.

Clang tooling lets you have access to a lot of information about your program, but it works at the translation unit level. It works file by file, basically. PDBs work at a whole program level right they're sort of the linker version of clang tooling so you have uh the final version you have the optimization info you have the address of each function you have uh all sorts of platform specific information as well as the global sort of global analysis of relationships between things so So it's really, really interesting, useful.

It's also sort of prototyped because Microsoft's, their documentation of DIA isn't great. Their API is way worse than not great. It's pretty rough. I've actually, in my program, I have built a subroutine for trying to generate documentation for the Microsoft API, just because I was unhappy with it. So I call every function on every symbol I can find and try to figure out what functions are valid in what contexts. Just because the API doesn't make that very clear when it's okay

to call this function when it's not. That's funny. Yeah. So what I'm getting at with that is that it's not perfect. And I don't really know what I'm doing. I'm kind of fumbling around. But there's so much data that I've been able to get out

of it. And I would love to see some contributions if people are interested in what we're it. And I would love to see some contributions if people are interested in what, what, what we're doing here, because, uh, I would love to see, uh,

see this thing, have access to everything in the PDB, um, and see what kind of things people are, you know, do with it. Yeah. Right.

Well, we'll put a link to that in the show notes. And I know we have some listeners, uh, from Redmond. So maybe they'll, uh, hear your comments and work on that dia documentation okay i can't wait yeah okay so britney where can people find you online to find more information about this project and and all your other work yeah so i have a twitter uh it is at listen server and uh g And GitHub will be in the show notes.

So, you know, give me a tweet. Send me a link. I would be happy to interact with the whole of the C++ community. I love you beautiful people. So let's get out there and write some code, right? Sounds good. Okay, thank you so much for your time today. Thank you.

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

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.