Quote:Original post by stormrunner
I realize this may be ignorant, but I just have to ask - what would be a case for a singleton ? You have - in brutal fashion - destroyed the basis for almost all uses of the singleton pattern as it relates to game developement. The last bastion of defence, per se, lies in it's easy applicability for memory management or messaging schemes. But even that just seems like lazyness (i.e. Enginuity, signals and slots) ... so is the singleton applicable in any type of gamedev related task ?

Could it be? Do my eyes deceive me? Or did someone actually get the point of my post? I'll answer your question in a bit stormrunner, but first...

Quote:Original post by _the_phantom_
@stormrunner
the only case for a singleton i can think of is a logging system, where it could be argued that you do need only one and global access to log from anywhere.

I now await Washu to shoot that arguement down

I am of two opinions to that idea. The first is: KEEL Phantom. However, the second is much more interesting.
[Edit: Over the months/years I've looked back at this and contemplated fixing this. Frankly, I don't use singletons for logging, as it's not a flexible solution that can be easily removed when porting code. There are far cleaner solutions that I would suggest implementing, but I won't cover them here.]
You wish to log events, such events might be informational, warnings, errors, and debugging information. How can we accomplish such? The first, and obvious choice would be to make a logging singleton with a function that would take a state flag...something like: Write(LL_DEBUG, StringBuilder("2 + 2 = {0}") % result);. This seems like a fairly reasonable approach, and would be perfectly acceptable for an entry level logging system. But, lets make our functional requirements a bit more complex. First, we would like the ability to direct the logging system to multiple streams. You should be able to indicate the logging level for each stream. The levels are arranged in a hierarchical structure, like so:

• Debugging


• Informational


• Warnings


• Errors

So, if you select the Warnings level, your stream will receive Warnings and Errors, nothing else. Obviously, if you select the Debugging level then you are going to receive everything. So, here's the question, is the new design still suitable for a singleton? We'll, actually, yes. Does it have to be? No, but in this case I would consider it an appropriate use of the singleton pattern. Quite simply, you will most likely be accessing the logging singleton all over the code. And refactoring it out is not an option.


Another possible singleton would a concrete factory that you expose from a DLL via an interface (as shown in the UML diagram below). In this way the actual implementation details of the classes would be hidden from the client. This would also enable you to control the number of times that the factory allows the provided interfaces to be instantiated. In this way you can achieve your goal of guaranteeing only single instantiation of various types (Graphics object, Input object), but when you need to allow for multiple instantiation, you aren't bound to a singleton object, instead you just use the factory interface to obtain another pointer.


That should also answer Etherstar's question.

IFactory *f = GetFactory();
IGraphicsManager* graphics = f->CreateGraphicsManager();