Question

I keep hearing that global variables should never be used, but I have a tendency to dismiss “never” rules as hot-headed. Are there really no exceptions?
For instance, I am currently writing a small game in c++ with SDL. It seems to me to make a lot of sense to have a global variable with a pointer to the screen buffer, because all the different class that represent the different type of things in the game will need to blit to it, and there is only one screen buffer.

Please tell me if I am right that there are exceptions, or if not then:

• Why not, or what is so bad about them that they should be avoided at all costs (please explain a little bit)
• How can this be achieved, preferably without having to pass it to every constructer to be stored internally until needed, or to every call to a paint() request.

(I would assume that this question had been asked on SO before, however couldn’t find what I need (an explanation and workaround) when searching. If someone could just post a link to a previous question, that could be great)

Answer 1

Of course there are exceptions. I personally can’t think of a single situation where a goto is the right solution (or where a singleton is the right solution), but global variables occasionally have their uses. But… you haven’t found a valid excuse.

Most objects in your game do not, repeat, not need to access the screen buffer. That is the responsibility of the renderer and no one else. You don’t want your logger, input manager, AI or anyone else putting random garbage on the screen.

And that is why people say “don’t use globals”. It’s not because globals are some kind of ultimate evil, but because if we don’t say this, people fall into the trap you’re in, of “yeah but that rule doesn’t apply to me, right? I need everything to have access to X”. No, you need to learn to structure your program.

More common exceptions are for state-less or static objects, like a logger, or perhaps your app’s configuration: things that are either read-only or write-only, and which truly needs to be accessible from everywhere. Every line of code may potentially need to write a log message. So a logger is a fair candidate for making global. But 99% of your code should not even need to know that a screen buffer exists.

The problem with globals is, in a nutshell, that they violate encapsulation:
Code that depends on a global is less reusable. I can take the exact same class you’re using, put it in my app, and it’ll break. Because I don’t have the same network of global objects that it depends on.

It also makes the code harder to reason about. What value will a function f(x) return?
It obviously depends on what x is. But if I pass the same x twice, will I get the same result? If it uses a lot of globals, then probably not. Then it becomes really difficult to just figure out what it’s going to return, and also what else it is going to do. Is it going to set some global variable that’s going to affect other, seemingly unrelated, functions?

How can this be achieved, preferably without having to pass it to every constructor to be stored internally until needed

You make it sound like that’s a bad thing. If an object needs to know about the screen buffer, then you should give it the screen buffer. Either in the constructor, or in a later call. (And it has a nice bonus: it alerts you if your design is sloppy. If you have 500 classes that need to use the screen buffer, then you have to pass it to 500 constructors. That’s painful, and so it’s a wake-up call: I am doing something wrong. That many object shouldn’t need to know about the screen buffer. How can I fix this?`)

As a more obvious example, say I want to calculate the cosine of 1.42, so I pass 1.42 to the function: cos(1.42)

That’s how we usually do it, with no globals. Of course, we could instead say “yeah but everyone needs to be able to set the argument to cos, I’d better make it global”. Then it’d look like this:

gVal = 1.42;
cos();

I don’t know about you, but I think the first version was more readable.