Elysian Shadows

I've been doing c++ for the last month or so and something has been bugging me. Everyone uses singletons - fine. But why use singletons over namespaces? I've failed to find an easy to use singleton structure on google so I've just been doing namespaces + classes for now. I don't see why singletons are apparently better, considering some of the issues I've read about them? I understand that if done right it helps keeps things together but I don't really see much of an upside.

For note - I used singletons/"static" classes in c# fine. I've just yet to find a way to implement singletons in c++ that I'm happy with.

edit: Oddly enough I just came across one such limitation. Concider this:
A singleton for ObjectManager would be a far better help. So - can anyone help me with getting/finding a c++ singleton implementation?

A good link for singleton technique below ->
http://www.devarticles.com/c/a/Cplusplu ... rn-Part-I/

I had a quick look but from what I can tell I can't control when to construct/destruct the singleton. This is why I never went for it when I came across it - but I just had an idea.

I can use Init/Shutdown to control when the specific system is alive/dead (Especially during shutdown when order can matter.) IIRC from when I last read this, the destructor is called right before application end........ or is it called when the main game class's destructor is called?

Point is I need to be able to init/shutdown when I choose. I don't care so much about having code laying around till the end of the application as generally the singleton will be around from game initialisation till shutdown, nor do I care that much when the class is constructed. For now anyway, I don't see me using singletons for anything else other then utility classes or things that require only one class (Graphics/audio devices, input/object/texture/"asset" management, etc).

It's far too late - I get up in 6 hours :P I'll have a closer look at that link later. Goodnight all.

I think Singletons are an overused, destructive design pattern. Any design that allows dependencies to literally pop out of somebody's ass in the middle of a member function of another class is just asking for trouble.

Singletons are promoting a spiderweb, clusterfuck pattern of design with untraceable dependencies and no interoperability rather than carefully planned, delicate designs which factor in dependencies and provide for modularity of code.

Live-Dimension, what you've been doing is actually a step worse than singletons, imho. Rather than a singleton, where each dependency is at least acknowledged with a Singleton::getInstance(), you're literally using a global variable in its own namespace (if I understand you correctly)? The problem of initialization/destruction with a singleton is going to be the same thing. If you have a global variable allocated on the stack, it is instantiated at program start and destructed at the end.

Honestly, the best piece of advice that I can give you is to steer clear of any design pattern that allows for any global, unregulated access to other components. There are far better, more methodical ways to achieve the same thing.

The Elysian Shadows engine has a SINGLE singleton--which is only used for debugging purposes to step into and out of classes/components (it is the friend of every subsystem class).

Honestly, the best piece of advice that I can give you is to steer clear of any design pattern that allows for any global, unregulated access to other components. There are far better, more methodical ways to achieve the same thing.

I haven't had enough dealing with OOP yet to know of any better ways. Any books or methodologies you think might be beneficial for me to look up?

The only singleton I have in my game project is a Logger class, because I only need one, and only one file to write to. Multiple logger classes accessing the same file would lead to possible read/write conflicts in my case. So in relation to that, do not use a singleton just because you want just one instance of an object. Use a singleton when you are absolutely positive that having more than one will break the program, causing it to crash or behave in a very unexpected way. In a case where it is odd to use more than one instance of a class, you will still have the common sense to create only one instance, and find a way to have components of the program access that instance, so making it a singleton is not going to accomplish anything to fool-proof your code writing.

That's my kind of mindset. If i only want the class to happen once/it can only happen once, why should I not make sure it cannot be made into multiple instances? I know how to code but I've never done a project like this. I've never had to mess around with object/texture managers or really setting up a proper rendering pipeline. Hell, I'm not even sure on some of the more basic things like defining input from multiple devices.

But I'm learning!