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.

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?

The second part, about global access, is somewhat more subjective. Perhaps you really want global access to this object. In that case, go ahead and make it global. I think global access is nearly always the wrong thing, but it really doesn’t matter. If you want global access, use a global. If you don’t want global access, don’t make it a global. Neither case requires a singleton.

I also think you can solve the prob­lem get­ting those depen­den­cies vis­i­ble. Don’t you think you can assign a sin­gle­ton instance to a mem­ber vari­able of a class that needs it

Sure, you can do that. But then (1) why does it need to be a singleton, why does it need to be globally accessible, and (2) you still have no way to ensure that it’s never used in the “other” way. That’s what’s icky about singletons. You don’t know if these hidden dependencies exist. They might all be made explicit as you expect, but there might also be a number of“hidden” uses scattered around your code. You don’t know.

IMHO, I think it is not a bad idea to use Singletons in order to avoid having multiple instances of an object (i.e. the Model) and have a global access to the single instance.

I agree with you about the fact that Singletons increase hidden dependencies. But I also think you can solve the problem getting those dependencies visible. Don’t you think you can assign a singleton instance to a member variable of a class that needs it?

Doing so, you make the dependency visible and give yourself the opportunity to remove the single instance constraint if you made a bad assumption about it.

Does it make sense? Do I have to apologize for my english? :)