Posts Tagged ‘build

01
Aug
11

Inlining and #includes

I’m on build coverage tonight, meaning I’m working until 2AM. Not the most glamorous aspect of the game dev industry, but when you’re trying to hit beta, making sure we have solid builds for QA every day is pretty important. So at least I’m important. Right?

So, the incremental build failed on me in an interesting way this evening. A header failed to compile because there was a class method defined (inlined) in it that used a function that wasn’t declared in any of the included headers. This, in and of itself, isn’t a particularly interesting failure. In fact, it’s a fairly typical, easy-to-catch-on-your-own-machine failure, one that you can usually shoot your fellow devs with nerf darts for causing. What made this particular instance interesting is that the check-in that broke the build wasn’t the one that broke the code.

Of course, it’s fairly common for a perfectly valid piece of code to expose a flaw in another piece of code, but I just couldn’t seem to figure out how the original code, which clearly called a function that wasn’t declared in any of its included headers, had ever compiled. My first thought was that maybe before this check-in, the header had included another header that had included the necessary header, but when I checked, none of the included headers had changed. It turns out the issue was that the new code changed the method from private to public.

Previously, the method had been private, meaning that it was guaranteed not to be used by any other translation units, so, even though the header was included by other files, that particular method was expanded. In the source file for the defined class, the header include was preceded by an include for another header which did declare the needed function. Once the method was made public, that method became expandable in other translation units, ones that may not have had the missing header in their includes.

This fix for this particular issue is incredibly simple — add the necessary header to the includes. But what’s the moral here?

  1. Always include all of the necessary headers for your code, and don’t rely on compilation to tell you whether you’ve done so. If you’re worried about build times or violating the one definition rule, use include guards. Actually, always use include guards. It’s a tiny amount of effort and extremely low-risk for a potentially epic payoff. (If you name your guards after the namespace and class that they guard, your chance of naming collisions is slim.)
  2. Please, for the love of all that is good, compile your code before you check it in.
Advertisements
26
Jul
11

Yes (/WX)

About a month ago, I realized that I was learning a lot and not writing it down. So I decided to start writing it down. A month later, I don’t remember what I learned that was so important, but I figured I should just start writing. Some of it will be technical. Some of it will be common sense. Most of it, you’ll probably have heard before somewhere. I’ll start with something that I tend to re-learn every project.

Treat warnings as errors: Yes (/WX)

I know some of you are saying, “But I plan to use that unused variable later!” or “Hey, I *know* that variable gets initialized in one of the branches of my if case, so it’s okay.” To put it bluntly, you’re wrong.

If you’re not using the variable now, replace it with a TODO comment, which has at least some chance of reminding you that you were supposed to do something with it. (No, it’s not a good reminder, but trust me, one more warning in the inevitable sea of warnings will not be any better.) And as for that variable that you know is going to be initialized in one of those branches, when was the last time you touched a piece of code and it never changed ever? That never happened? That’s what I thought.

But why should you care that your cup overfloweth with warnings every time you build your solution? Well, for one thing, they’re warnings, not beer. They’re an indication that something is behaving not quite as intended. It may mean a little bit of code bloat, which is not such a big deal. Or it could mean that you wrote this code when you were really tired, and you didn’t actually use the variable you thought you were using. But if it’s only a warning, amid a sea of warnings, you’re not going to notice until your code doesn’t do what you thought it should do, and it’s the middle of crunch and you’ve just forced QA to fail the build that was supposed to go to cert.

Or, more importantly, you might find that some other project that you didn’t build locally does treat warnings as errors and then your change fails on the incremental build, and everyone will point at you and laugh.




About

My name is Maitland Lederer, and I’m a video game developer. I learn stuff you probably already knew and have opinions you've probably already heard. I figured it might be a good idea for me to start writing down the stuff I've learned so I don't have to relearn it. It's not, like, great wisdom or anything. It's just things I happened to learn, usually today.

Header photo by D Sharon Pruitt, used under a Creative Commons License.