And even when you think making an object global is a good idea, it often isn’t. Taking your resource manager as an example, why does it need to be global? The vast majority of your code shouldn’t need to know about it. Pass it around to the few classes that do need it. Or perhaps even better, ask yourself why you need a resource manager at all. “Manager” classes are always a warning sign. What does it mean to “manage” a resource? What kind of management does it need? Can’t a resource take care of itself? What responsibilities does a “manager” have? Rename it, split it up into multiple smaller classes, or remove it entirely. And very likely, you’ll find that there’s no need to make it global either.

You’ll also find that it’s not a true “global” in any case. It has a limited lifetime (it doesn’t make sense to “manage” a Direct3D resource before your D3D Device has been created, or after it has been destroyed, for example).

As to your main point, several points come to mind:

• what would your proposed mutex do? Just ensure that calls to instance() are serialized? That’s only necessary at construction (and not even then, assuming a compiler which properly implements C++11’s memory and threading models), and I would much rather just explicitly control the object’s construction in any case (see below), making that problem go away entirely. So doing so really solves a non-problem. And it won’t make the actual “inner” object instance thread-safe either. So I don’t buy the “safety” thing. Is there some other safety benefit I’m not seeing?
• I’ve come to disagree with the “order of construction” argument. Most of the problems I’ve encountered in the real world with singletons have been related precisely to order (and time and place) of construction: with a singleton, I simply have no clue when it’s going to be initialized. That is often a problem, especially for objects you may want to parametrize (which file should your logger output to, for example? Presumably your resource manager needs to know about your OpenGL context or Direct3D device (Resource managers tend to imply people are making a game, in my experience :)). With singletons, passing such parameters isn’t easy, because you have no clear point at which it is instantiated.

So if order of construction matters, that’s a very strong reason to avoid making it global. Construct your objects explicitly, in main or another function.

Of course, if you absolutely want global’ish access, you can create the object locally in main, for example, and then set a global pointer to point to it. Then you still control order and time of construction, while also providing a means for code to access the object globally.

But generally, my rule of thumb is that globals should not depend on order of construction (they shouldn’t need to access other globals).

You say yourself that sometimes global variables are necessary, but there is no need to impose the single instance rule. I certainly agree with this.

However, suppose you have a template [i]class Singleton[/i] which provides a singleton-like design pattern for [i]class T[/i]. To me, this seems to provide a safer global access than a plain global (because one can fairly easily add inbuilt mutexes etc. and one doesn’t have order of construction problems). On the other hand, because the Singleton design is implemented in its own template class, it doesn’t actually prevent other instances being created.

What do you think of this approach? Perhaps it would be clearer to rename [i]Singleton[/i] to [i]Global[/i], but that name could be somewhat confusing too (since only one object of that type can be instantiated). However, it seems to me that this essentially matches your criteria (imposes globality, which is sometimes desirable, but not strictly single instantiation), but in a safer manner than a normal global variable.

You can suggest the use of Boost or std::unique_ptr and quite literally get a totally negative response coupled with “but what about speed?!” The game industry is so for-profit and so overly-pragmatic (if you can even call their practices practical) that they constantly harm themselves repeatedly before taking a step back and saying, “oh look, guys, everyone else solved this problem years ago!”

It’s stupid.

But yet I agree with the fact of creating useless objects like in the car example, people forget that objects are good for data encapsulation in a way that only the object has access to the raw data and provides functions to manipulate it.

At first I was inclined toward your stance on using a simple global variable which is init’ed perhaps, with the app startup. Upon reflection however, I’m not sure I see the difference between this and the singleton pattern, other than that the later packages the global variable (as a static) and has a self contained initialisation. Some might even argue that this is more in keeping with Single Responsibility Principle. What do you think?

Thanks for the thought provoking and detailed discussion by the way. It’s very pertinent to the code I’m writing as we speak :)

On the other hand, in your second snippet, it’s not clear where this settings object comes from. And I can’t follow the uses of the object. If I start at the construction of the settings object, I immediately run into “it’s stored into a singleton, which is… just there. At some point, someone might call getInstance on it, but I don’t know who does that, or when or why.

So I disagree with your analysis of dependencies.

On the other hand, it is certainly more convenient to just make the settings object globally accessible.

So go ahead and do that. But it doesn’t need to be a singleton to achieve that goal. Just a single global/static instance will allow everyone to access the settings object if they want to. There’s no need for messing around with singletons and all the other problems they cause.

Singletons are global, but globals are not singletons. If you need a global, that doesn’t mean you have to use a singleton.

SettingsClass.getSetting(‘showTooltips’)

Or you have it be an instance var on the Application class which is referenced by an instance var on the Controller class which is referenced by an instance var on the view and so on… You end up with the following:

self.parentController.parentApplication.settings.getSetting(‘showTooltips’);

Which is a (very!) hidden dependency. Or you do…

Application’s init: self.viewController.showTooltips = settings.getSettings(‘showTooltips’) viewController’s init: self.view = this.showTooltips

…and create tons of code with a multiplicity of by way of property names, making changes such as refactoring a serious sweat.

What I’m asking really, is what about the case for the singleton (or at least a global variable) where it reduces complexity for application areas which aren’t resource intensive?

Like many things in programming isn’t it a trade off between simplicity and covering all potential future cases?

I agree that Connect has been somewhat of a joke for many years but I must say that since Doug took over as the PM for Feedback at MS, things have started to move (slowly, but still moving) in the right direction. There’s still a long way to go but I hope they will get there…