CppCast - C++ Game Development at Blizzard

Episode Date: March 16, 2017

Rob and Jason are joined by Ben Deane from Blizzard Entertainment to talk about C++ game development and more. Ben started in the games industry in the UK in 1995, when he got hired at Bullfrog straight after graduating from university. While there he worked on several games there like Syndicate Wars and Dungeon Keeper. By the late 1990s he had stopped using C and was allowed to use C++ at work. In 2001 he moved to Kuju Entertainment and did a couple of games on XBox and PS2, then in 2003 he was hired by EA again and moved to Los Angeles, where he worked on the Medal of Honor series. He's always been a network game programmer, and in 2008 after a project cancellation at EA, he joined Blizzard as a lead engineer on Battle.net, working on technology for all of Blizzard's games. Today he's a principal engineer at Blizzard and the technical lead on the Battle.net desktop application. He's also a functional programming hobbyist who tries to use what he learns in Haskell to write better C++, and in recent years he has given several C++ conference talks at C++Now and CppCon. News Insomniac Games Cache Simulator Functors are not dead: the double functor trick Pi Day Challenge I'm Done - Geschafft: Words about the Future of my Blogs Check for const correctness with the C++ Core Guidelines Checker Ben Deane @ben_deane Ben Deane on GitHub Ben Deane's Blog Links Blizzard Entertainment Blizzard Careers CppCon 2016: Ben Deane "Using Types Effectively" CppCon 2016: Ben Deane "std::accumulate: Exploring an Algorithmic Empire" Sponsor Incredibuild JetBrains

This episode of CppCast is sponsored by Incredibuild. Accelerate your C++ build by up to 30 times faster directly from within Visual Studio 2017. Just make sure to check the Incredibuild box in the C++ Workload VS 2017 setup. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice, CLion, ReSharper, C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at jetbrains.com. Episode 93 of CppCast with guest Ben Dean recorded March 15th, 2017.

In this episode we discuss Kant's correctness and a cash simulator. Then we talk to Ben Dean, technical lead on Battleman at Blizzard. Ben tells us about his history in the game dev industry and gives us a preview of 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?

Pretty good, Rob. How are you doing? Pretty good. Not too much news. We took about a week and a half off catching up from that. Yeah, but our listeners don't actually know that. No, we're time jumping. It's fine. Yeah. Anyway, at the top of our list, I'd like to read a piece of feedback um this week i got a tweet uh after listening to cpp cast episode 80 i searched for dwarf language but just got hits for

kuzdul i'm guessing that's not the right one um i was not familiar with kuzdul apparently you know i was aware that jara tol, the writer of Lord of the Rings, had actually created the Elfish language. Apparently, he also created the Dwarven language, which is Kuzdul. I did not know the name of it. I did not know the name of it. I guess I should have assumed he for the Dwarf Linux debugging language, right? Oh, yeah, that's the Dwarf file format, I guess is what he was going for there. You know, I read the tweet and I'm like, what is that?

I don't remember that. Oh, right. Yeah, it was when we were talking with Backtrace about debugging, right? Right. Sounds right. We'll hook you up with the JetBrains giveaway, Parsley, and

we'd love to hear your thoughts about the show as well. 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. Joining us tonight is Ben Dean. Ben started in the games industry in the UK in 95 when he got hired at Bullfrog straight after graduating from university. While there, he worked on several games there like Syndicate Wars and dungeon keeper by the late 90s he'd stopped using c and was allowed to use c++ at work in 2001 he moved to kuju entertainment and did a couple of games on xbox and ps2 then in 2003 he was hired by ea again and moved to la where he

worked on the medal of honor series so he's been a network game programmer and in 2008 after a project cancellation at ea he joined blizzard as lead engineer on Battle.net, working on technology for all of Blizzard's games. Today, he's a principal engineer at Blizzard and the technical lead on the Battle.net desktop application. He's also a functional programming hobbyist who tries to use what he learns in Haskell to write better C++, and in recent years, he's given several C++ conference talks at C++ Now and CppCon. Ben, welcome to the show. Hi Rob, hi Jason, it's good to be here. Thanks for having me. You've touched on like every game studio, I mean, you know, within some reasonable definition of every. Well, I mean, it's true that the games industry, you're only sort of two handshakes away from most people in the games industry.

I don't know about every game studio, but, you know, working at EA certainly is a big studio. And, of course, you know, Activision Blizzard is another behemoth of the games industry, if you like. Okay. So, yeah, I guess it's true to say I've been in the games industry long enough that I know quite a few people. So, you know, as you know, I like to ask how you got your start. And this says you were already in the games industry in 1995. So I'm trying to figure out, like, what computer you grew up with in the UK. Were you using a ZX Spectrum or something like that? I started, yeah, I started exactly with a 48K Sinclair Spectrum.

Okay. Legendarily unreliable. I think we went through about six of them. Well, it has a bare edge connector on the back, which is the joystick interface, so you just wiggle that and the thing reboots. So, yeah, doing type-ins from magazines on the Spectrum and then on the BBC Micro. My first programming was kind of basic on the BBC Micro and some 6502 assembly.

So, yeah, I've written a multiply routine on the 6502. I know that's something close to your heart, Jason. Yes. You know, then I got an Atari ST. I was a bit of a gamer. That was a 68,000 machine, so that was a nice assembler, too. And then when it came to deciding what I wanted to actually do with my life, I graduated high school.

I thought math was too hard and physics was too boring at the time, so I chose computer science and the rest is history. I almost ended up with an Atari ST myself. My parents were deciding what computer to get after the Commodore and went with a PC instead of an Atari, and I almost kind of wish I'd had the chance to own an Atari ST. Yeah, it was a neat machine. And I hear it's still in use today uh for certain audio

applications um i guess i guess people still like it there's still a sort of hobbyist and even maybe a non-hobbyist scene for it well that's cool and ben your first game studio looks like was bullfrog um we were going back and forth with your bio and uh you mentioned someone who interviewed you for that job right someone kind of well known in the industry yeah yeah so my first interview was fresh fresh face grad and i was interviewed by peter molyneux um that was an interesting interview he's a he's a cool guy um that was 95 so that was kind of the era of the puzzle interview you know the puzzle interview was very much in vogue microsoft was was top the heap. And it was all about, everyone was doing puzzle interviews in the tech industry. And of

course, Bullfrog was no exception. And Peter is very much a puzzle nerd, I guess, much like myself. Luckily, I was enough of a puzzle nerd that I'd heard basically all the puzzles he could give to me. So I think he had no choice but to hire me. That is a funny kind of interview where it comes down to, essentially, have you heard this puzzle before, not can you actually solve this puzzle? Yeah, that's not an interviewing style I espouse these days. Yeah, it's definitely fallen out of favor.

Yeah. Okay, well, Ben, we've got a couple news articles to go over and then we'll start talking about the work you've been doing at Blizzard, okay? Okay, great. Okay, so this first one, I'm guessing you've probably already heard about this, but I guess GDC just occurred

two weeks ago, the Big Game Developer Conference, and we've got some slides here from a talk from Insomniac games about their cash simulator which looks pretty cool and i haven't watched the actual talk i'm not sure if that's available online but we have the slides here and it looks like they really had to do some interesting things in order to get this cash simulator to work yeah i mean, I'm looking at this and it seems like you had to be a little crazy to decide to set down the road of making one of these.

Yeah. Yeah, I thought this was pretty cool. And I like that they're open sourcing it. I looked through the slides. I haven't had a chance to watch the talk yet. But yeah, the stuff they did uh was was really good and uh significant savings from the slides you know so one of the they one of the slides said uh they had they had lots of little things going on uh processing little objects and and using this cache thing

they were able to get uh more than a a millisecond saving, which is a significant portion of a frame at 60 FPS. That's still outside the world of what I generally think in for savings. So a half a millisecond of each frame essentially they were able to regain.

Yes. I would be very happy if I was to make an optimization that gained a half millisecond per frame. Okay. This next one, functors are not dead, the double functor trick. I feel like we've had so many articles talking about functors lately. And this is on Jonathan Bakara's blog. What did you guys think about this trick?

Jason, what did you think about this one? Well, my first thought was it can be done a little bit better with combining lambdas and C++17, variadic using, that kind of thing. And I think he mentioned that towards the end of the article that he had some commenters pointing out the possible use of lambdas,

and he put in some example of how to do that. Oh, I guess he actually has a link to one of my C++ Weekly episodes at the bottom. I didn't see that. Oh, yeah, there you go. Yeah, I thought of that too. That was a good episode. Do you know, is that how, I know there's a proposal, there was a proposal, there is a proposal for std overload. And it seems to me that what you did is a very easy way of implementing std overload.

I believe that is, in retrospect, supposed to be the canonical implementation of it or something. Although I opted for taking things by universal reference and forwarding them in, and I guess the other version takes them by copy and moving them in, which results in effectively the same thing. It's just mine's actually slightly more complicated than it needs to be. Right. Yeah, this article also made me think, actually i recently it's funny like the day before i read this article i had run into the same kind of problem uh that is looking up an item in a set where what you want to look up isn't the isn't the actual value type of the set but it is comparable

to it and uh i had found you know i thought to, there must be a way to do this. And I kind of had an inkling in the back of my head of how to do it. And I looked on cpreference. And indeed, I found that set supports lookup, a templated lookup with a transparent, what's called a transparent comparator. Yeah, can you, can you explain that? Because I saw links to that in the Reddit discussion about this article, and I'm like, wait, I have never it just the day before was very much like that. In other words, you have a comparison operator that takes a thing of the value type and a thing of the type that's comparable to it, and you write two of them so either way around they can be compared. And then, of course, it needs to provide the comparison between the value types themselves. So you end up with three overloads.

And then you can pass that. The other crucial thing is you need to define a type, a typedef inside that struct just called isTransparent, and it doesn't matter what you define it to. So you can say using isTransparent equals int or whatever, and that is a signal to the set, to the standard library, that your operator is transparent, and then these lookup operations on the set,

count and find and such, the templated versions of those become available for you to use. Okay. And so you can call and you can look up an item which isn't the same as the value type, but is comparable to the value type using the operator you've supplied. Oh, I see. So it essentially adds another overload to the value type using the operator you've supplied. Oh, I see. So it essentially adds another overload to the index operator?

I'm not sure if it's the index operator, but it's certainly find and count and a couple others. I'd have to look at cpreference.com to reverse. Okay. All right. Huh. That's pretty crazy. But, yeah, it's strange.

I'd seen it just the other day. And I found myself wondering. Okay, all right. Huh. It's pretty crazy. But yeah, it's strange. I'd seen it just the other day. And I found myself wondering, so that's on set, and it's probably on map also, I think. Right, that's what I was thinking, map, yeah. But it's not on an ordered set and an ordered map, because of course, I think it could be done, but you'd need the transparent hash struct as well, because you'd need to, assuming that the thing you pass in not only need to, assuming that the thing, so the thing you pass in not only needs to be comparable to the key, but also hash in the same way as the key. So it represents a subfield of the key often, which you're using as the hash key.

Would that then require a second set of hash buckets or something to be able to implement that? I don't think so. I think you just need to be able to hash the the thing which is not the value type in the same way that you have to value type to get to the right hash bucket to compare the right the thing that matches if you like right okay all right interesting okay and we had another article we wanted to mention uh from theency Boss Boss blog. And this was the Pie Day Challenge. Yesterday was Pie Day. I missed celebrating it. I'm sorry, but how does one celebrate Pie Day?

There are many ways you can celebrate Pie Day. Some pizza pie, a cookie pie, all types of pies. I went to a British pub and I ate a steak and mushroom and Guinness pie. There you go. It was a good celebration. I just completely missed it yesterday. Anyway, so he put out this challenge to write an expressive way of determining pie, a code example for determining pie in the most expressive way possible.

And he picked the winner here and chose the code sample. And you had some comments about this one, Ben? Yeah, I saw this a week and change ago, and I thought it was interesting, and I knocked up my own solution in 45 minutes. The algorithm was fully explained. It wasn't a difficult program, but the expressive part was the interesting part to me.

And, of course, I knew it was going to be very, very subjective. And I knew that whatever he picked for the winner, people would complain in one way or the other. I think they complained about capital snake case, variable name for cons. People are always going to find something. But I thought the winner was really good, used ranges. That was very nice. I also went through the exercise with a couple of members of my team at work, and it gave us a good chance to talk about code

and talk about what we think expressive means and whether that means to some people just plain integer-controlled for loops are very expressive, very easy to read. They're used to that. To others, for example, my solution, I didn't use ranges, but I effectively wrote an algorithm, because it was basically a count if of a generate n. So I wrote a fused algorithm that did count if of generate n in the same way that the ranges solution did. So different people find different things expressive and readable,

and that was really what I took away from that. I would like to ask which one generated the more efficient code, but it looks like that would be difficult to compare with lots of random number generation and uniform distributions and that kind of thing going on. Yes, Yeah. Not sure about that. The one thing I learned actually was you got to love C++.

The uniform int distribution is a closed range, right? But the uniform real distribution is a half open range. So that was something that I didn't, I guess, appreciate. I knew that the int distribution was a closed range, but I had never used a lot of real distributions. Interesting. Okay. Next one is a post from Modern C++ Blog.

Here's another blog we've been talking about lately because there's been just so much content on it. And apparently the reason there's been so much content lately is because Rainier Grimm has actually been translating all of his blog posts from German to English. And this post is just summarizing how he's now finished that work. He's translated all of his old blog posts. And going forward, any new blog posts he writes

will be done in German and English at the same time. I commend him for that. That had to have taken a lot of work. Yeah, I think he said here he's translated 130 posts and he started doing this April of last year. So it took him about a year to translate all the posts from German to English. So, you know, amazing work. And some of these posts that we've gone over have really been quite, quite good. Yes, definitely.

Yes, I saw he's writing a book as well. Yeah, I believe it would be his third book if he does. Yeah. Have all the other books been in German? Is he writing this one in both German and English? Do you know? I'm not positive. He says this one will be

in English. Oh, I thought he said it would be in English only. Maybe I'm wrong. I believe in Korean. I think I read English, German, and Korean. Or he's got a Korean publisher interested and he's going to find a German one, I think was the quote.

Oh, yeah. Right. And his last book, the C++ Standard Library, was only in English, I believe. Okay. It's an e-book. It's on the side of the webpage for anyone who cares. Okay. And last article is from the Visual Studio blog. Obviously, we talked a lot about Visual Studio 2017 in our last episode.

This is one topic which we didn't mention that I thought was worth bringing up. Checking for const correctness is now available in the C++ Core Guidelines checker. And this actually calls back to an article we discussed on the show several episodes ago. I'm not sure how long ago that was, Jason, with Bruce Dawson talking about the benefits of

const correctness that he found several issues, I believe, in the Chromium library that he went ahead and fixed and got some pretty huge performance gains. Yeah, and that was arguably bugs in Visual Studio as several things that he was talking about for how its optimizer handled const things. Because there were some cases where removing const gave him better results because it wasn't very good at deciding which code section to put the code in, I believe. Yeah, so at least one of them was a bug,

but I think some of them were just, you know, fixing a problem where you should have been using const. Right, yeah. But anyway, the core guidelines checker will now be able to tell you if you should be using const which will uh hopefully get you some of these performance gains as well what are you gonna say ben uh i was gonna say that i'm not really uh using the core guidelines a whole lot yet in my in my sort of everyday coding either either my work coding or my hobbyist coding.

It's definitely on my list to look at more. I think I did try running the core guidelines checker over part of my code base today, and it came up with a few things. It came up with nothing serious, but things which indicated to me that using the core guidelines is definitely a kind of shift of, of mindset. So it recommends a lot using spans. It doesn't like pointer arithmetic.

It doesn't like a rate of pointer decays. Um, so I, I think the core guidelines are a good thing, but it's a kind of a change of habits. There'll be a while coming at least for me. Yeah. And you are dealing a lot more with,

um, kind of memory and reinterpret cast and high performance kinds of things that the average C++ developer doesn't usually need to deal with, I think. But there's plenty of sort of everyday code that could possibly benefit from using spans and not doing pointer arithmetic. It's just that I'm so used to, and I think a lot of people are very used to, just stepping through arrays, incrementing pointers, stepping through arrays with integers. It doesn't like indexing into arrays using non-constant expressions. So it seems like a sea change in just the way you write code to take account of that. Right. To avoid memory errors, essentially.

Yes. I mean, there are plenty of rationales for the CPP core guidelines. Okay. Well, Ben, let's start just giving us an overview of what exactly you do at Blizzard on a day-to-day basis. Okay. Well, I lead the team that makes the Battle.net desktop application, and that means I manage eight other engineers.

I work with designers and program managers to plan and schedule features and releases. My day-to-day is a lot of meetings, a lot of tech design, code reviews, kind of architectural conversations with other engineers, and coding whenever I can. So that's kind of what I do on a day-to-day basis. Inside Blizzard, I'm also known as a bit of a C++ evangelist. I try to keep up to date with what's happening in the C++ world and pass on information about it to my colleagues. And I've given a few conference talks, and I always practice them at work, usually at least once for my immediate team and sort of once again for a wider audience.

That seems more helpful than... To have people to practice your talks in front of seems like that would be very beneficial. Yes, it is. Because they, especially a crowd of game programmers, they will be the first to ask about, well, what's the performance of that? Doesn't that incur an extra copy? Do you really need to do that?

Could you do that a different way? They're really great at pointing out old things like that. Cool. So I guess by working on the Battle.net desktop application, you don't so much work on the actual games, console games

or otherwise. Is that correct? Right. Yeah, I don't work on the games themselves. I don't do any console programming, but I do do cross-platform programming because, of course, we ship on Windows, we ship on Mac. I've also, in the past, been at positions at Blizzard where I wrote server code, so that's Linux.

So it's Clang, it's GCC, it's Visuals Geo. Okay. So if you can talk about it, does any of the code in the Battle.net core stuff get shared with the rest of the team? Do you guys have a core set of libraries or anything? Well, there's some sharing that goes on. And in general, we'd like to do more of it. We do tend to have a robust internal engineering

community, but it's also true that all of the games pretty much are different genres and have different problems to solve. As you might expect, they get free reign over what goes into their codebases, obviously. While some things

can be shared, every game is different in its needs. Okay. How did you wind up working on Battle.net and not the games at Blizzard themselves? You have this long history of working on games like you said Dungeon Keeper and all these other ones. Yeah.

Well, I guess it's just the arc of my career. I lucked out in that the very first title I worked on, All these other ones. Yeah. Well, I guess it's just the arc of my career. I lucked out in that the very first title I worked on, I did the network programming. And it turned out that being a network games programmer is a very good thing for your career. Networks are the only things that don't get faster when computers get better. So the latency between London and Los Angeles is pretty much the same today as it was in 1995. Darn speed of light. So, and, you know, there are hard problems that still remain hard problems, and it's all about hiding latency and making a good experience for the player.

So I had done, you know, a suite of games over my career, and in pretty much all of them, I had some role in networking. And the ones I'd done at EA, in my transition to becoming a lead software engineer, I passed through sort of lead network or sub-lead of the network part of the game. And so, you know, although I've done pretty much, I've touched most parts of games at this point in my career,

when I came to Blizzard, it was just, it was Battle.net that kind of caught my eye. And, you know, I've always loved working on networks, and that's why I do it. So it was a great opportunity. So we touched on just a little bit, you have to deal with Windows and Mac and Linux, and you're doing network programming. What kind of cross-platform issues do you have to deal with? So that's a good question.

So most of the time, I try to write platform-independent code, and that's a good thing. And, yeah, as you say, sometimes it's a little... You have to deal with different compilers on different platforms and they move at different speeds and you can update them at different speeds. So you're almost always using some kind of lowest common denominator. Right.

So, for instance, a good example of that is on the Mac right now, I don't get to use ThreadLocal because it's not supported on the tool chain that we use. The max we have to support. Yeah, it's only been in the last three months on Xcode or something, right? Right, and I believe it's also tied to you have to have a modern version of the OS as well. It's frequently the case that the OS vendors deprecate their OS's faster than we can so you'll know if you follow Blizzard

that we just announced that we are planning to sunset XP and Vista support that's an example we're still supporting it right now but obviously once we can sunset that it gives us the opportunity to move forward in all kinds of technology areas and have a better experience for players and a better deal all around.

I think STL tweeted, you know, well done to Blizzard and Firefox and something else I forget for dropping Windows XP and Vista. And he hopes he can get rid of support for the potato OSes, as he put it, some days. I was going to say, things occasionally get better on the compiler front. So a few months before Visual Studio 2015 was finaling, I don't know if you remember, but this was a year, 18 months ago, something like that. So Stefan Laue made a post on Reddit CPP asking what they wanted it to have. And I happened to be sitting at my computer. He made the post and I saw it was only a few minutes old.

So I made a comment and what I asked for was a switch for strict standards like dash like dash stood equals C++ 11 or 14 that we have on GCC and Clang. So I got in first with that request, and it was upvoted, so lots of people wanted it. And then Steve Carroll, the dev manager for MS Visual Studio, was on the thread too. And, you know, so things do get better. So here we are. Microsoft has slash stood C++ latest now, and they actually took that on board, which is great. Well, thank you for that.

Well, I mean, it was clearly an idea whose time had come. Sure. Yeah, that's the weirdest platform. I mean, like, I appreciate Microsoft's products. And like you said, I mean, Apple is frankly kind of horrible about sunsetting stuff way too early compared to Microsoft that perhaps keeps things around far too long for their support. But I have no idea what I was going to say next. Well, I mean, the reality of the situation is that

if an appreciable subset of your customers are using an OS, you must support it. Yeah. At least, you know, I don't know about Apple and Microsoft. They have their own plans. But for us, it's kind of the reality of the situation. And the same is true kind of for things like wine. So we try not to,

we don't actively support wine, but we try not to break it, you know, mostly. And there have been cases in the past where I, you know, the Ballonet desktop app, we made a release and it didn't work on wine

because of an unimplemented feature, a thing in wine that wasn't implemented yet basically a piece of the windows api that we were using that wine just didn't have yet uh and because somewhat strangely for a game dev i've been running linux at home for 10 years or more so i was used to using wine and so i noticed this and i was able to uh put in a fix uh suggest that my patch didn't actually make it into the wine build, but it did fix people's ability to play, and later on, the person who was responsible for that piece of code in wine

was able to make the correct fix. That's cool. And your company doesn't mind if you do that, kind of submitting back to open source projects? Well, in that case, it was something that really I had looked into on my own time, you know, at home. It wasn't something that really I did anything at work with. Right.

So, yeah, I mean, there's a growing number of people who want to do open source work, I guess. And, you know, Blizzard is generally pretty good about that. There are channels you can go through. number of people who want to do open source work, I guess. And Blizzard is generally pretty good about that. They're a challenge you can go through. That's cool. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors.

IncrediBuild dramatically reduces compilation and development times with unique process virtualization technology. The tech transforms your computer network into a virtual supercomputer and lets each workstation use hundreds of vital cores across the network.

Use IncrediBuild to accelerate much more than just C++ compilations, speed up your unit tests, run more development cycles, and scale your development to the cloud to unleash unreal speeds. Join more than 100,000 users to save hundreds of monthly developer hours using existing hardware. IncrediBuild is already integrated into Visual Studio 2017.

Just make sure to check the IncrediBuild box in the C++ workload in the Visual Studio 2017 setup. So you said you're kind of a C++ evangelist at Blizzard. How important do you think C++ is at Blizzard? Are there competing languages there or anything like that? Has Blizzard ever thought about implementing parts of games or parts of Battle.net with other languages? Well, I would say that C++ is really important for games performance. And pretty much everything we ship that runs on someone else's computer at home, it's pretty much all C++.

Okay. And, you know, performance is a massive reason for that, and C++ in the games industry is really the lingua franca. Now, of course, like every games company, we have tools and things which are written in other languages python and you know if you if you go to the uh the the open positions at blizzard if you get if you go to the web page of the open positions you'll see them looking for people who can do python uh of course maybe lure um c-sh Sharp, Java, JavaScript, all of these languages are used.

But C++ is definitely, when we ship bits to players' machines, it's pretty much all C++. Well, I guess I'm a little surprised. I didn't know if I expected everything to be C++. I might have expected some of the GUI tools, whatever, to be written in C Sharp. It seems to be somewhat common for people to do that. Oh, they definitely are. Okay. I mean, the internal tools.

The internal, right. Yeah. Sorry, I didn't mean to interrupt you there. Oh, no, no, no. I mean, like I say, C++ is just really important for performance, and not just games, but for all software, I think. Too often we forget that performance is a feature. And so with C++, it's really important

to be able to read the compiler output, I think, and to use that learning to write code that you know the compiler will be able to make fast. And the work that you're doing, Jason, and that Matt Godbolt is doing, evangelizing that view, I think is great. It's fun. Plug in some stuff, see what the compiler generates. Yeah.

And on that note, I think that Rust is interesting, even though I haven't spent any time programming in it, because I get the impression that you can also reason about what the compiler is going to generate with Rust, similarly to how you can with C++. And we just got our announcement that C++ Now, one of the keynotes, is going to be from one of the main Rust guys. Oh, right. I was wondering if you had any thoughts on that, if you've spent any time playing with Rust or anything.

I have not looked at Rust, I have to say. I hear whisperings about it. Maybe I should look at it. Yeah, I mean, I'll be interested to hear that keynote. Yeah. The very first C++ for the Commodore 64 thing that I did, someone responded with, well, look, you can do the exact same thing in Rust.

And I was like, oh, that surprises me. Right, right. I think it's, yeah, this thing of knowing what the compiler will output and being able to read assembly code, I remember before I had that skill and attaining that skill was really a step change in my ability to debug and be effective in C++.

So I highly recommend it to any engineers out there who aren't yet used to dropping down to assembly and looking at what the compiler does. It's really useful. Right. So you've given several talks at C++ now and CppCon over the years. Do you have any favorites you want to mention? Well, I try to do my best with all of them. now and cpp con over the years do you have any favorites you want to mention well i there i tried to do my best with all of them i've given three full talks and one lightning talk the first talk i gave was sort of in at the deep end it was at you know c++ now is 90 minute talk slots and the

audience at c++ now is just you know they know chapter and verse of the standard. They're very experienced implementers. They're very experienced argumentarians. I don't know. No, it's a great, seriously, it's probably my favorite conference. And it's a great crowd to give a talk to because they are all interested in finding exactly what the best way to do something is. They're finding finding the truth. It frequently happens that, you know, certainly from my point of view, there are there are several, maybe many people in the audience who are more experienced with the stuff I'm presenting than I am myself.

But in terms of talks, my favorite... Well, I missed C++ Now last year, unfortunately. My brother was getting married on the weekend that C++ Now was over. That's not an excuse. Well, I was sad to miss it, but on reflection, the wedding was fantastic. But sort of to make up for that, I gave two talks at CPPCon. And giving two talks was actually a lot of work. My talks tend to be long on preparation.

Lots of preparation, lots of coding, lots of exploring goes into the preparation of my talks. And, for example, the one I gave about, I gave one about std accumulate, and in preparation for that, I basically re-implemented nearly all of the algorithms in the standard library in terms of accumulate over about a month of evenings. Because I think it's really important to be able to show working code in talks,

just like your talks, Jason, and Chandler also does a great job of that. Yes. Chandler does a great job of that. But my favorite, my favorite talk was probably the using types effectively talk I gave a CPP con. It was about the third or fourth iteration of that talk.

I'd done it several times internally to different audiences. It's a, it's a, it was a great talk because it had audience interaction, which is something you rarely get to experience. And it had a couple of real nuggets in there, I think,

or things that stuck with people. And I've heard good feedback about it. That's the talk that's probably my favorite. They're all my children, but I'm really happy with that one. And now I realize that's the only of your three talks that i have not yet watched or seen in person oh well now i've now i've oversold it pretend i didn't say that just go into a blind get some homework for tonight

i think it's already in my youtube watch list actually because i did hear good things about the talk at the conference. Cool. I mean, the other thing I would say about giving talks is that more people should be encouraged to give talks. And you don't have to be a world expert on things to give talks. I started giving talks because there were talks I wanted to hear. So if there's a talk you want to hear, the best way to hear it is to give it. And like I say, you don't have to be an expert. There's a lot of value in the journey talk,

in the talk of, you know, I'm an engineer just like anyone in the audience. And here's what I've learned in exploring this thing. And, you know, here are the pitfalls I learned. And here are the cool things I learned. That's a very valuable kind of a talk. Right. And don't be at all intimidated by what you just said five minutes ago about how the audience at C++ now knows more than you do. Oh, they absolutely do, but that's not a reason to be intimidated. They are all very helpful and friendly.

Collegiate. You know, yeah, yeah. I think that's a good way to put it. It's good to be able to take feedback well and take it constructively. That's definitely a skill. But yeah, C++ Now, I love that conference. So at C++ Now, which we haven't yet mentioned in this interview, you and I are going to be giving a talk together. Yes, we are.

Constexpr All the Things is the official name of it. That's right. That was your title, and I thought it was a great one. Which I think I might have actually gotten from Matt Godbolt, but I'm not sure. Okay. So I'm curious how practical you think Constexpr is going to end up being in a high-performance C++ code,

like in your real day-to-day life as we get more and more support for it. Okay, that's an interesting question. I think it will be practical. One of the problems with constexpr is that well first of all in 11 it was kind of this curiosity it was very limited because to do most things you needed to put on this

sort of extreme functional programmer hat I might say because you're only allowed one expression per function body and so extreme recursion is the order of the day and so I tried that out in my time. A year or so ago, I went down the rabbit hole of ConstantExpert. Because at that time, Microsoft weren't supporting generalized ConstantExpert of C++14.

And I didn't know when they were going to be. So I thought, I'll grit my teeth over this and I'll do everything in 11 style. And I managed it. I mean, some of it was difficult because I started out with math functions. And in particular, some of those are difficult to do well because to do them in a runtime performance manner, they might involve casting

or fiddling with floating point representations, which you just aren't allowed to do at compile time. And so this is one of those problems is that constexpr is kind of weakly specified to the compiler. The compiler is allowed to do it at compile time, but nothing's forcing it to do it at compile time. And so mixing efficient runtime code with constexpr code is kind of difficult.

But I think with stuff that's coming, code with constexpr code is kind of difficult. But I think with stuff that's coming it's just going to get better. So with C++14 we've got generalized constexpr. We still can't fiddle with the innards of floating point representations or anything like that, but at least

you get more than one expression per function body. You can write things in a more or less runtime efficient way. And with 17, we get more yet. We get, in particular, constexpr lambdas, which in theory we, I think, could have had before in the same way that we really could have made. We could do the same thing that lambdas do in in c++ 98 but you know the the new syntax is really

that much nicer and makes them that much easier to use and therefore that much more widespread so there's a couple of i don't know if they're quite proposals but things i've seen along the lines of the ability this ability detect, enforce or at least detect compile time versus runtime execution of your constexpr function. I've seen sort of some people have mooted making constexpr part of the type. I'm not sure about that. Maybe a constexpr operator is something else I've seen. I haven't seen a constexpr operator is something else I've seen. I haven't seen a constexpr operator option.

Yeah, it's similar to the noexcept operator. Oh, interesting. Okay. At least in syntax, in that kind of usage. So this is constexpr. You can then pass it by an expression of some sort to say, if this other thing is constexpr, then make this one constexpr also or whatever? I'm not too sure of the ins and outs. I think it's for really what you want to do is detect when you are working at compile time

and differentiate that from when you're working at runtime. For the reasons I explained. To have good performance at runtime, you have a bigger toolkit. Right. So, yeah, so our talk is an attempt to answer that question of, you know, is

Constexpr finally usable by sort of non-wizards in C++17? So I don't want to give away too much about our talk, but I will say, I just wanted to add a little comment here, that some of the things that we've done in preparation for our talk, I really want to be using in some of my C++ Weekly episodes that I'm working

on right now, but I am holding off. Because I'm like, oh, I could really use that right here. But no, we're going to hold off on that. Okay, cool. Well, you know, once Aspen comes around, it's open season after that, I guess.

Yes. Yeah, I was going to say something. Oh, yeah. So the other, of course, win that Concepts gives us is not just in – so it's a win to start with, and I know that you know this, Jason, because of ChaiScript, if you can reduce steps from your build chain. Yes. So if you can move things into the compiler that were previously perhaps,

I don't know, scripts that generate code from, you know, files, UI definition files, for example, or some other kind of code generation you have using Python scripts as a pre-step of your build chain, something like that. But the more you can move into the compiler and the more you can move into the same sort of area of your build chain, something like that. The more you can move into the compiler and the more you can move into the same sort of area of the code base, I think that's a win in itself. Yeah, you know, now that you mention that,

I wonder if there might be, like, people who prefer removing stuff from the build chain, like yourself and myself and, I don't know, other people, if we have all had to deal with large-ish cross-platform applications. Because you get that much more pain when you have multiple build steps and you have to worry about multiple compilers on multiple operating systems.

Right. Yes. Yeah. So I'm just wondering, at Blizzard, we're talking about all these C++ kind of newer features. Are you able to use the latest standards? Are you using C++ for the team now? Subject to compiler support. Again, this varies from team to team. For my team, we actually...

I'm really happy to say that we, about this time last year, we upgraded from Visual Studio 2010 and we're now on 2015. And so one of the issues when you are making a product that is essentially an evergreen product, so it's not any more shrink wrap product you just you just release and then you go on holiday um you have to keep supporting this product one of the issues is that there's never a good time to to upgrade your tool chain um you have to figure out a way you can't just oh i'm starting a new project so i'll use the i'll use the latest thing no you you're stuck your codebase. You've got to find a way to bring it forward and upgrade toolchains.

And there never seems to be a good time to do that kind of work, because it's not the kind of work that is making a feature that players see. Right, and we did mention this earlier, but for listeners who aren't familiar with Battle.net, I mean, this is kind of the software that's used to organize online games for any Blizzard game, right?

Yeah. Is there a description of it? Sure. It's the online networks. It's the network gaming service that Blizzard has. I mean, I think that's a good description. Just one more question, maybe. What have been your thoughts about the

game development industry lately are you seeing any big changes with regards to C++ development in the game industry at large I've certainly seen a lot of changes in my time I mean

lately, yeah lately too but I mean to give you some idea, so when I started programming games, we really had no idea what we were doing. I mean, looking back at it, the code was legendarily bad. So, I mean, anecdotes abound. Have you heard of the wing commander bug? It's quite famous.

I don't think it's about that. That was a thing that would happen all the time. So I don't think this, according to Wikipedia, this bug didn't actually make it to a full-fledged release. But basically there was a bug on shutdown in Wing Commander in the mid-'90s. I guess it was early-'90s. The EMM386 memory manager would have an exception on shutdown uh now the the fix for this was not to fix the exception or anything like that the fix for it for this was to um

hex edit emm386.exe to change the message to thank you for playing wing commander so that when when you quit instead of saying you know exception whatever from EMM386, it would say thank you for playing Wing Commander. So things like that, anecdotes like that abound in the games industry. At Bullfrog, it was a very interesting time. It was something I look back on very fondly,

but many of our practices were quite simply insane. The project organization we had was... So Bullfrog actually had a company coding standard that said various things, and one of the things it said was we had to put all structs in one header. All structs used in the whole game

went into structs.h, and everything included that. And all the function prototypes went in extern.h, same way. And, you know, what that did to our compile times, you can only imagine. But thankfully, the projects were smaller back then. Source control was not a thing then. We had a shared drive on the network. And I had, we were working in C.

Ben.c was my playground. And mark.c and mike.c were my fellow programmers. And then we just used to split files up when they got too big. So about 15,000 line files were not that uncommon. We just used to break them up. Variable names were another terrible thing. I think the best way to describe the whole situation is that we just, we piled up code on top of code until it did what we wanted.

Sometimes we would quite literally stack if statement on top of if statement line by line to add conditions to the if statement when we just, you know, a spaghetti code writ large. Wow. So that was the good old bad old days, if you like. So there was a move from assembly to C sometime around. I mean, I worked in C in my early career, but sometime around the early 90s, the games industry shifted from assembly to C sometime around, I mean I worked in C in my early career, but sometime around the early

90s the games industry shifted from assembly to C and people claimed that C could never be as fast as the hand optimized assembly code and they were very distrustful of it. And then sometime around the late 90s there was a move from C to C++ and people claimed that C++ could never be as fast as their hand optimized

C code and they were very distrustful of it. And right now we're beginning to see some acceptance of STL features in games. So it's the same story again. For a long time, the STL has had a bad rap in games. And most of the time, let's be honest, that's warranted because of the containers and their allocators not being a particularly good fit for games. But I think people are starting to appreciate that the STL is not just the containers. In fact, it's not even mostly the containers.

If you're familiar with the work of Alex Stepanov and Sean Parent, you probably would look on the algorithms as being the soul of the STL. And we have things now also like SG14, and they're doing a great job engaging the games industry with the standardization process. So we've got people like Guy Davidson and Brittany Friedman, and they're doing great things. Jason, anything else you wanted to ask today?

I think that's it. Okay, Ben, where can people find you online if they want to find more information about you? They can tweet me at Ben underscore Dean. I have a blog that I sometimes update, www.lbenno.com slash blog. Yeah, I mean, tweeting is a good way to reach me. Or they can meet me at a conference.

And you will be at C++ now. I'll be at C++ now, yeah. Okay, thanks again for coming on the show today, Ben. All right, and just a final note, we're always hiring good engineers at all experience levels. So if anyone has any aspirations to work at Blizzard, that would be a great thing too. Sounds great, thanks. Sounds great. Thanks.

Thank you. Thank you. 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.