Quote:Original post by Nitage
You also need to explicitly destroy the pointer in the example I gave, you'd have to wrap it in a smart pointer for it to be automatically destroyed.
Singletons are overused, but that doesn't mean that they don't have uses.
I'm currently only using one for my debugging system (which handles logging etc.).
Every piece of code needs access to it and there should only ever be one instance, so it's an excellent place to use it.
Making things like your main application class a singleton is a bad idea. You may only ever want one intance, but it's unlikely that you want every piece of code to have access to it.
Most of the time singletons can be replaced with just a normal class with one instance; actually, I can't think of any situation in which a singleton would be better. The bad things about singletons, and global data in general, is that their not explicit, and in some cases, practically hidden. While this might not be that bad in your personal projects, it would be a mess for pretty much anyone else, or even yourself after 2 months, not to mention the mess that it would cause when you try and reuse some of it. While using a singelton for a logging subsystem might look okay, what happens if you want to have two logs? Instead, a simple Log class would probably be best, or even better, you could just pass around a std::ostream and not even bother making a class.
Here's some advice if you still need to use singletons: isolate their use to the highest-level game-specific code in your game.
Finally, some of the best advice I can give is to follow the unix philosophy: write components that do one thing and do it well.
[Edited by - bytecoder on June 13, 2005 1:37:50 PM]