[quote name='rpiller' timestamp='1357223603' post='5017110']
Stick to a singleton if you need something like a global.
[/quote]

Sorry, but if you've been using singleton's "instead of" globals then you have still been using globals during the past 8 years. A singleton isn't better than a global just because it's wrapped up in a fancy class, and using a singleton because "you need something like a global" is a terrible reason to use the pattern. You should use a singleton if you need a singleton; that is:

• If there must only ever be one instance created. Note that this is different from only wanting or needing one instance -- if you only want or only need one instance then don't bother with additional code to enforce it and instead only create one -- the singleton is appropriate when it would be an error for there to be more than one instance.
• If you need global access.

Unless you need both of those requirements the singleton is not the right pattern for your situation, and it's exceedingly rare to genuinely require that there must only be a single instance.

If you "need something like a global" then use a global, don't shoe-horn your code into an unnecessary pattern under the impression that your code is somehow better because you avoided a global -- you haven't avoided it at all -- a singleton by definition is global, and still has all of the potential problems associated with that, but now has the added baggage that you're also enforcing the (usually unnecessary) single-instance requirement as well. Writing more code to enforce a requirement you don't actually have -- that there be only one -- can never possibly be simpler than just using a global and not creating more, and it reduces the flexibility of your code.

A quick search for singletons will turn up plenty of additional discussions on the topic, but I'd like to suggest that singletons should be added to the list of things that should usually be avoided along with goto, globals, et al.

For C++, I'd recommend reading C++ Coding Standards by Sutter and Alexandrescu. The table of contents by itself is helpful, but the full book contains discussion like reasoning and exceptions to the general rules. The only problem is that it predates C++11.

I just came across this the other day. Scott Meyers' range of Effective C++ books are also a great read on best practices

A singleton is clearly better than a global because it's wrapped up in a neat little class and you get the benefits that classes get. Because that allows for more flexibility and organization than a loose global variable. Yes, they have the same scope, but one adds more benefits than the other, does it not?

No, it doesn't. The one and only thing you get out of a singleton that you don't get out of any other global (class) is the enforced restriction that there may only be a single instance, and this is an additional limitation that simply isn't necessary in the majority of cases. If you have a global variable or function and you want to wrap it in a class to provide encapsulation, validate changes, or whatever then by all means put it in a class, but it simply doesn't need to be a singleton, and unless you actually need the highlander rule ("there shall only be one!") you're not gaining any additional benefits from choosing a singleton instead of a regular class.

You obviously understand that globals can potentially cause problems, so the suggestion that a singleton -- which is still global and therefore still susceptible to all the same problems -- is better doesn't make sense. The benefits you listed aren't the benefits of a singleton, they're the benefits of a well designed class which probably doesn't need to be restricted to a single instance in most cases. Singletons increase coupling and make your code less flexible by discouraging re-use. Wrap your variables or functions in a class if you want to -- but why make it a singleton if it isn't an error for there to be more than one?

A singleton IS a global, so you're breaking your own rule of "never use a global" every time you create one.

If you have a genuine need for a singleton then by all means use one. If you're happy to use them in your private code-bases and you aren't experiencing problems then by all means continue to use one. But if you're going to suggest to a less experienced programmer that a singleton is a suitable replacement for a global when it imposes a restriction that isn't usually relevant and leaves the data global an alternative point of view needs to be provided.



...and in the interest of staying on topic, I think the more general case of the point I've been trying to make is:

• Whenever possible, choose the most suitable tool (whether that be a language construct, a language itself, a piece of software, etc.) for the task you are trying to accomplish. Learn the tools that are available to you and their intended purposes so that you don't need to try to use a screwdriver to hammer in a nail.

//EDIT: I just wanted to specifically respond to the following in addition to the above:

I don't get belittling the benefits of what a class offers and clearly " just because it's wrapped up in a fancy class" is belittling what a class offers in it's tone.

I'm not belittling what a class offers at all, I'm belittling what a singleton offers. Singleton is a specific design pattern with additional constraints above-and-beyond those normally imposed by any other class, and to suggest it be applied as a blanket solution to a problem it doesn't actually solve -- that is, trying to avoid the potential pitfalls of globals by using a specific type that is still global -- just doesn't strike me as something that should be in a discussion of "good habits". Use a singleton if you think it's actually the appropriate thing, but if all you need are the benefits of a class then just use a regular class rather than a singleton.

The tone you're picking up on is directed specifically at the mis-application of a singleton, not at the use of classes in general, and certainly not at you personally -- we're all trying to provide helpful information, and I simply felt that one of your points amongst an otherwise good post needed correction. A singleton just isn't appropriate as a blanket solution to situations where you feel the need to use a global -- it doesn't change the scope (which is the original problem) and it introduces additional constraints that may or (more likely) may not be necessary.

And in general, what I should consider for become a better game developer and make better games?

Finish what you start ... when you start a game, finish it.

This leads to a natural corollary, Don't start things that are too big for you to finish.

[quote name='TheSasquatch' timestamp='1358625548' post='5023275']
the free online repository site I'm using has a built-in issue tracker
[/quote]

Which free online repository site are you using?