Hmmmm....

I had to read this article a couple of times and I may still be missing something, but the author gives me the impression that he's a conceded asshole. Did anyone else get that vibe? I mean, he never actually gives any supporting arguments for why he thinks singletons are so bad and instead just spouts off a bunch of crap making them look like something to trump cancer as the next most feared disease. He goes on to imply that all those who do not agree with him are idiots, for his path in the one true way to enlightenment. Maybe it's the blue hair talking, but that immediately makes me want to do the exact opposite.

Then again, maybe I'm just cranky.... It's 1am and I'm trying to get this selection shader to behave before I grab a shower and crash for the night.

Anyway, to answer your question, I don't really see anything fundamentally wrong with singletons. Like all things in programming, there are trade-offs. The bottom anonymous post mentions some good ones. There are as many ways to solve to an engineering problem as there are engineers. If you're that concerned with it, I would suggest reading up on the Singleton pattern to understand the thinking behind it. Then read the reasons for avoiding it and make your own decision.

Personally, I use Singletons in my own code. Many of the top level systems in Ratrace use them too and we've never run into problems that would have been solved by not using them, although I'm sure some of the uber veterans like Mike or Kain have.

-Rez

I agree with you Rez. I think he is another one of those people that thinks that "My way is the best and every other way suck". Reminds me of console war a bit actually

I have used singleton classes in a few places where I think they fit well in comparison with other design patterns. They do have positive sides I think, but as all other patterns, they don't fit everywere.

Even the most beautiful rose has thorns you know.

An interesting tack that my team has taken, which I haven't seen anywhere else, is to indirect the game systems via a singleton. We have a GameManager class that holds all of the core systems (e.g. renderer, sound, input, etc) and that is used as a singleton. We don't run into the order-dependent initialization issues, because only one singleton is initialized and inits things in the appropriate order.

One poster mentioned that he thought he never needed more than one renderer, but then a customer wanted that. Such an indirection scheme would allow you to do that. Hell, it could even preserve the same interface and have an overloaded function to access renderers other than the default.

I honestly think that there's nothing wrong with singletons, but people love to have their own opinions as to The Right Way (tm) of things. It's true, singletons can be abused, but so can just about any other construct in C++, if you really want to. I've found you can never stop someone from being stupid (abusing code), you can simply provide a more logical way to do things.

All of the reasons to not use singletons that the article writer sited are actually not reasons at all. Our game engine architecture is incredibly modular and flexible, while using a singleton (the GameManager) that holds the global core systems.

Hey folks. New to the board, but I've had Mr. Mike's book for some time now (actually, have both first and second editions).

Originally posted by rezination
I had to read this article a couple of times and I may still be missing something, but the author gives me the impression that he's a conceded asshole. Did anyone else get that vibe?

Funny you should mention that. The author is Washu, who I remember being a very much opinionated dink. I used to frequent #gamedev, and never had much respect for him. I think I remember a few times where he banned people (including me, I believe) from the channel for disagreeing with him, or no reason at all.

Just thought I'd share my personal experience.

Originally posted by SirTimothy
Funny you should mention that. The author is Washu, who I remember being a very much opinionated dink. I used to frequent #gamedev, and never had much respect for him. I think I remember a few times where he banned people (including me, I believe) from the channel for disagreeing with him, or no reason at all.

Just thought I'd share my personal experience.

That's hilarious. Unfortunately, even in a highly creative field such as this, you will always find people like that. It's sad but true.

Then again, yesterday we found a bug that was caused to a global singleton that wasn't getting destroyed until global destruction time, which is after we destroy the memory manager. This caused a crash on close. Yours truly wrote the singleton.... The fix was easy though; I just changed the singleton implementation I was using.

-Rez

Originally posted by rezination
Then again, yesterday we found a bug that was caused to a global singleton that wasn't getting destroyed until global destruction time, which is after we destroy the memory manager. This caused a crash on close. Yours truly wrote the singleton.... The fix was easy though; I just changed the singleton implementation I was using.

-Rez

I heard that a lot of problems in games are attributed to custom memory manager implementation. I wouldn't know, as we're not using one. Really, for our small game, new works just fine.

Though, I'm going to try to convert our engine to use threads, which singletons and global access, etc, don't really make easy.

We've been using new & delete forever. Our memory manager isn't as much of a manager right now as it is a tracker. This still causes bad things when objects are destroyed at global destructor time. Since Ratrace is for the PS3, we have very little room for error when it comes to memory. I'm sure someone will end up writing a much better memory manager than what we have now.

-Rez

to summerize my experience about singletons: at first I liked them, but now I'm away using singletons because I've got problems when there are too much singletons in my application.

for small classes that don't use other singletons it's ok, but I had problems with the initialisation-order and delete-order (not really a problem on a console, but on PC). and small changes in sourcecode could trigger large runtime-changes (when is the singleton initialized), so now I use explicit initialisation, but still (global) getter-methods for the instance for bigger subsystems because I have more control about the lifetime of an object.

Singletons have always been for those key systems that every other system depends on. They're not to be used for every little datum you want to share throughout your application.

They are a design pattern. A tool. Saying that singletons are evil and wrong is like saying that hammers are evil and wrong. When you want to drive a nail you grab a hammer. When you want to cut a board you grab a saw. When you need to create an object that will be used by many systems in your program but that there can be only one copy of that object, you grab a singleton.

Just remember to learn other tools - when all you have is a hammer, everything starts to look like a nail....

Well said.

-Rez

"Goto is the buldozer of coding. Sometimes, the buldozer is just the right tool for the job. Not often, but sometimes."
-- LordBob

Reminds me of Mike talking about how he changed 'goto' to 'goat' in someone's compiler as a joke. Heh, I don't I'd ever have thought of that one.

I can't resist:
xkcd.com/292/

-Rez

yeah, and xkcd.com/135/ too.

Those cartoons are quite funny, the person who writes them seems to like their velociraptors .

Originally posted by rezination
Hmmmm....

I had to read this article a couple of times and I may still be missing something, but the author gives me the impression that he's a conceded asshole. Did anyone else get that vibe? I mean, he never actually gives any supporting arguments for why he thinks singletons are so bad and instead just spouts off a bunch of crap making them look like something to trump cancer as the next most feared disease. He goes on to imply that all those who do not agree with him are idiots, for his path in the one true way to enlightenment. Maybe it's the blue hair talking, but that immediately makes me want to do the exact opposite.

Then again, maybe I'm just cranky.... It's 1am and I'm trying to get this selection shader to behave before I grab a shower and crash for the night.

Anyway, to answer your question, I don't really see anything fundamentally wrong with singletons. Like all things in programming, there are trade-offs. The bottom anonymous post mentions some good ones. There are as many ways to solve to an engineering problem as there are engineers. If you're that concerned with it, I would suggest reading up on the Singleton pattern to understand the thinking behind it. Then read the reasons for avoiding it and make your own decision.

Personally, I use Singletons in my own code. Many of the top level systems in Ratrace use them too and we've never run into problems that would have been solved by not using them, although I'm sure some of the uber veterans like Mike or Kain have.

-Rez

I am a little bit biased (for reason you'll understand easily) but I can certify you that Washu is all but an asshole. And even if he was (and again, he is not), his singletonitis articles (because, guess it, he wrote 3 articles about that issue, not one) is still a valuable one.

Th ething is that people don't read them carefully. If you read it again, you'll see that he doesn't say that you should not use singletons. He says that you should not abuse them - which is quite different.

Singletons is a tool, everybody will agree on that. The fact is that there is a pool of people on gdnet who think that 99% of the time, singletons are not used correctly - most of the time because the specificity of this pattern makes it utterly difficult to use correctly (I am part of this pool of people). As a consequence, we often tell people to not use them unless they are aware of the problems they can induce. Washu does one step further, as he shows that most "typical" uses of the pattern can be replaced by a far better code structure - one that makes more sense and that will be easier to maintain in the end.

Weaknesses of the singleton pattern are numerous. The first one is in its very definition : it ensures that only one instance can exist at any time. If later in you design you discover that this singletonized class should be instanciated twice, you're screwed. In the end, the singleton pattern can make refactoring portions of code more difficult.

Point is that every time I used a singleton in my career (and I have been a professional C++ developer for 9 years now), I had to reconsider this choice later. Singletons make sense if you have to represent something that can exist only once, and that can be instanciated/opened/... only once. A good candidate could be a particular, application-wide exclusive device driver.

But most of the time, the class you're sinlgetonizing is just another class and there is no specific reason to limit the number of object you can create with this class.

A logger ? What's the problem with proving a bunch of functions to do the job instead of encapsulate everything into a class and make this class a singleton ? A logger don't even have a state - so a class representation doesn't make much sense.

A resource manager ? A renderer ? A sound manager ? My current engine supports the creation of N of them. What's the point of limiting the number of objects you can create ? Is it a design error to create 2 resource manager? One is managing the global resources (textures and models for the inventory) while the other is managing the level resources (map, specific enemies).

Another problem with the singleton pattern: the complexity of implementation. Writing a goog singleton class in C++ requires a good knowledge of the language - not an average one. While everyone understands that the GoF is only showing simple examples of a possible implementation, the GoF code is often copied verbatim into "production" code. The result is a singleton which is not a singleton at all, as we can still instanciate more objects using the copy constructor, and we can easily break the core by inadvertedly deleting the object itself. Consequence: since implementint a correct singleton requires a good knowledge of the language, it's often a good idea to not use the pattern if you're not completely familiar with the language itself.

In the end, when it comes to the singleton pattern, one has to open his mind: since it's more difficult to get rid of it than to add it later, it's always better to not use the singleton pattern when designing a solution. It also gives more design opportunity later in the development process.

That was the subject of the articles from Washu. He's not fighting against singleton; he's fighting against singletonitis.

Now, I don't really like seing friend being considered as a "conceded asshole". At least, be a man, and tell him. But leaving that on a website and moving away is just unfair.

Sorry man, didn't mean to hurt your feelings. I made no accusations as to the ass hole level of this guy since the sum extent of my interaction with him was reading the article a couple times while waiting for code to compile at 1am. I merely said he gave me that vibe (and was not the only one to pick up on that). He very well could have given that exact speech in front of me and given off a completely different feeling just by tone and body language. Emotions are often lost in text.

Once again, I'm sorry if I insulted you or your friend. My tact levels are pretty low during crunch time. If you make it out to GDC this year, let me know and I'll buy you a beer.

-Rez

I feel a bit guilty too, it was wrong of me to judge other people, especially people that I have never met. I want to apologize to Washu and yourself as well, Emmanuel.

I still think that I would have listened a bit better to the things he wrote, if he had pointed out some better arguments to why he feel like he do about singletons as he do. But that is only my opinion, not an excuse.

I agree with Tarviathun's strategy wholeheartedly.

I agree so much that I am going to quote it here for emphasis:

An interesting tack that my team has taken, which I haven't seen anywhere else, is to indirect the game systems via a singleton. We have a GameManager class that holds all of the core systems (e.g. renderer, sound, input, etc) and that is used as a singleton. We don't run into the order-dependent initialization issues, because only one singleton is initialized and inits things in the appropriate order.