next »

[Average Software]

I did notice that you used a singleton in C++, which is an unforgivable sin in my eyes.

I'll bite. Why is it such an unforgivable sin? I know the singleton pattern is much maligned amongst students of such things, but for practical purposes I find it an incredibly useful pattern. Most of the major subsystems in my game are singletons. I only have one renderer, one texture manager, one physics system, one animation system, one UI manager, one entity manager, one sound manager in my game. Why not express those things as singletons?

Because in C++ they can much more cleanly expressed as namespace modules.  Singletons are a hack used in languages that force everything to be in a class.  They simulate free functions and data.  C++ supports these things directly, there is no need for singletons.

On a more pragmatic level, a class is supposed to be a data type.  What the hell good is a data type that only allows one instance?

If your class can't support multiple instances, it shouldn't be a class in the first place, it's really a static bundle of data and functions, in other words, a namespace module.

[Klaim]

That said...


they are a good way to explicitely ensure that a global object state/system is initialized and terminated. Exploiting RAII isn't limited to function and type member scope objects.

Personally I like to use Singleton pattern to represent some system state like the graphic system or the audio system. The point is that I have initialization and termination code in the constructor and destructor of those systems AND my Singleton implementation forces explicit creation/destruction. Functions in namespace arent as "safe" as this.

But that's not valid if your system don't have a "state".

Most of the time, people use Singleton like global variables that you're not sure when it is created (at first use often) or destroyed (never???). That is a wrong way to use this pattern, at least in my way of thinking.

Most of the time, the Troll lives on the fact that the participants of the discussion on Singleton pattern don't use/thinkg the same implementation of it, and it makes hard to have a clean discussion about it.

Personally I avoid Singletons if it's not for a 1.unique 2.environnement system 3.that have a state - and I use a Sintleton implementation that require explicite cration/destruction in such cases. I think it's ok only in those cases.


Omg I fed the troll...

[BorisTheBrave]

Average, you need to be careful when you say you don't like singletons. Everyone is going to assume you mean you don't like global shared data, because there is a considerable movement against that sort of thing. But you just mean you don't like singletons as an implementation of global shared data in C++.

Yeah, lambda are the only C++0x feature I authorize myself to use because I know it have been implemented on all my target compilers and they say it's easy to implement (as it's basically a simple way to generate functors.

I applaud your professional approach of targeting several compilers, rather than just one and going for untested "platform-independent" code.

[Klaim]

I applaud your professional approach of targeting several compilers, rather than just one and going for untested "platform-independent" code.

Yeah, the next step for me is to setup some continuous integration tool on my server to make sure everything compiles on all target platforms/compilers while I'm developing. But I'm still a noob in all this so it's not setup yet. Anyway I'm trying

[Average Software]

Average, you need to be careful when you say you don't like singletons. Everyone is going to assume you mean you don't like global shared data, because there is a considerable movement against that sort of thing. But you just mean you don't like singletons as an implementation of global shared data in C++.

That's a silly assumption for people to make.  If I say I don't like singletons, that's exactly what I mean!

The backlash against global shared data seems to be completely ridiculous to me too.  Some data is global and shared by its very nature.  Jumping through elaborate hoops to avoid this complicates your code, and in my view often leads to more mistakes than just accepting the fact that you have global shared data.

The loudest complainers seem to be the unit test crowd, who whine because global states ruin their unit tests.  If your testing methodology can't handle it, maybe you need a better testing methodology.

[BorisTheBrave]

That's a silly assumption for people to make.

You may think that, but it is still fact that other people will make it.

I am a proponent of removing global state, but I'm not going to discuss it here. Particularly as nearly all the legit exceptions happen come up in game making, as you say, by its very nature.

[LemonScented]

namespaces are nice and everything, but they don't do everything that a class can do, at least not as easily. You can't do data hiding particularly effectively by having stuff private and only having a public interface like you can in a class - sure, you can just put the interface in the header file and have all the data declared statically in the source file, but then you've got that data sat around in memory the whole time. You have to work harder to allocate, initialise and delete stuff because you don't have a constructor or a destructor, and as Klaim pointed out, control over when and how singleton data is created and destroyed can be pretty important.

I suppose what confuses me about the singleton hate is this: Everything in my personal coding style (which is fairly rigorous) has a justification. Not a justification based on semantics and theory, but because at some point in my past, I was bitten on the ass by doing things the "wrong" way, and sought to adapt my style to ensure I'd never get bitten in the same way again. In 20 years of coding games, the Singleton pattern has never caused me any grief or headaches. So, in concrete practical terms, what harm do singletons do?

[Average Software]

So, in concrete practical terms, what harm do singletons do?

The harm comes from limitations built into classes that don't belong there.

A class should not know or care how many instances of it exist.  If your program only needs one instance of an object, then that is part of the business logic of the program.  Singletons make the sweeping assumption that nobody will ever need more than one of these.  These kind of assumptions bite you in the ass in the long run.

sure, you can just put the interface in the header file and have all the data declared statically in the source file, but then you've got that data sat around in memory the whole time. You have to work harder to allocate, initialise and delete stuff because you don't have a constructor or a destructor, and as Klaim pointed out, control over when and how singleton data is created and destroyed can be pretty important.

This is simple.  You create an internal structure in the implementation file, and allocate it when needed.  Provide Setup and Teardown calls in your module, call them at the beginning and end of the module's usage.

This is actually less code than the traditional singleton implementation.  You only need to call Setup once, as opposed to calling get_instance or whatever every time you want the functionality.  The call to Teardown mirrors the call to delete the singleton instance (you are deleting it, right?).  This problem was solved long ago by procedural languages.  Singleton puts an unnecessary object-oriented spin on the traditional procedural module.

Further, most singletons (at least the ones I've seen) are active for pretty much the entire run of the program anyway.  Their data is basically sitting around in memory the whole time as is.

And just in case, because this has happened before, just because you only happen to have one instance of something in your program does not make it a singleton.  I have no beef with this.  A singleton is a class that actively prohibits the existence of more than one instance.  Some people don't understand the difference and completely misunderstand my points, thinking I'm criticizing something else.