Quote:Original post by M2tMI dealt with this also while building a framework around SDL_mixer, but didn't use a singleton. The problem here (if you want to call it that), is that the class in question only meets one of the 'singleton' criteria: it would be an error (more or less) for there to be more than one instance.
From personal experience they are best avoided, but when wrapping a c style library in a series of classes to enhance functionality I found it difficult to dodge a singleton. The special circumstances are that first, SDL_Mixer isn't really multi-instancable because it is based on several c functions which share a single state. And the second is that to implement a play list it seems you require a basic c style function pointer. At the time I knew of no way to cast between a class specific member function and a global c function, but I believe that mem_func would probably do what I need (though when I was having this issue nobody suggested it.)
In any case, it was a decent use of a singleton because the actual concept being wrapped could not safely have several instances without each instance knowing about the other ones so we knew if it was initialized and playing etc.
Nobody suggested a better alternative in this thread:
http://www.gamedev.net/community/forums/topic.asp?topic_id=520472
However, the other criteria - that global access is needed (or even desirable) - doesn't really apply here. Under normal circumstances only a small percentage of game code will need access to the sound system; as such, I'd argue that a singleton isn't really an appropriate solution here.
I ended up deriving the 'sound system' class from a 'single instance' base class that throws an exception if more than one of the derived type is created, and used static functions where C-style callbacks were needed. Not ideal perhaps, but I do think it's a better solution to the given problem than a singleton (at the very least, it shows that there are other solutions to this sort of problem besides using a singleton).