Singletons vs. static objects
Author
I''m always hearing stuff about singletons, but why not just have a class and make all variables and functions static?
This is what they did at the game company i worked at over the summer, and it worked just fine. I''m just curious why i never hear this mentioned though- everyone always seems to think in terms of "objects" or "singletons".
Maybe it is due to the fact that static classes lack constructors and destructors? This is a bit of a nuisance that I ran into lately- I wrote a static class which detects leaks in your code, but it''s a bit annoying because at the end of the program you have to say-
MemoryTracker::Kill();
whereas a destructor would be nicer. I don''t know- maybe there is some way to simulate a constructor/destructor in this case, without totally obfuscating the code?
Thanks,
Raj
You can, that works too. You could also ditch the class all together and have a package of functions with static (ie compile unit hidden) data members. Just depends on the situation.
IMO singletons aren''t as useful or necessary in C++ as they are in other OO languages (for various reasons they''re very important/useful in Java). I usually go the package of functions route.
IMO singletons aren''t as useful or necessary in C++ as they are in other OO languages (for various reasons they''re very important/useful in Java). I usually go the package of functions route.
It depends on what you''re trying to do. If all you care about is global access to a class or group of variables, then static classes or functions work well. If however, you want to dictate a design constraint that one and only one instance of a particular class exist, then you should use a singleton.
A singleton is not a global object, though that''s what most people use it for. It is a design constraint used to limit the number of instances of an object. The fact that any class in C++ designated as a singleton ends up having global scope causes a lot of confusion as to its real purpose. It''s an unfortunate side effect.
A singleton is not a global object, though that''s what most people use it for. It is a design constraint used to limit the number of instances of an object. The fact that any class in C++ designated as a singleton ends up having global scope causes a lot of confusion as to its real purpose. It''s an unfortunate side effect.
Hello RajanSky,
Static classes can have constructors and destructor.
Constructor is call before program is running during to loading of program into system memory.
Destructor is call at exit of program after return form main but before program is remove form system memory.
Now if you need to do something before exit like some kind of thread stuff that need to be done before return form main the you would need a method like your kill. I say this because at exit some things you could do during a program you can''t do between exit and program unloading, same as loading I don''t think you can create a thread until you are actual inside main.
Lord Bart
Static classes can have constructors and destructor.
Constructor is call before program is running during to loading of program into system memory.
Destructor is call at exit of program after return form main but before program is remove form system memory.
Now if you need to do something before exit like some kind of thread stuff that need to be done before return form main the you would need a method like your kill. I say this because at exit some things you could do during a program you can''t do between exit and program unloading, same as loading I don''t think you can create a thread until you are actual inside main.
Lord Bart
Author
Wow, thanks for the help guys, now the issue is a lot more clear to me
Lord Bart- I''m not sure if I understand about the constructors and destructors though... You are saying that they get called automatically? But the thing is, I have a completely static class (i.e. I am not declaring an instance of it *anywhere*) and then I put a breakpoint in my destructor for that class, and it never got called. I guess I could always just create a single object of type MemoryTracker, and then that way when the program ends, MemoryTracker''s destructor will get triggered.
It''s kind of a cheap and dirty solution though, so I don''t know, maybe there is something more straightforward.
Lord Bart- I''m not sure if I understand about the constructors and destructors though... You are saying that they get called automatically? But the thing is, I have a completely static class (i.e. I am not declaring an instance of it *anywhere*) and then I put a breakpoint in my destructor for that class, and it never got called. I guess I could always just create a single object of type MemoryTracker, and then that way when the program ends, MemoryTracker''s destructor will get triggered.
It''s kind of a cheap and dirty solution though, so I don''t know, maybe there is something more straightforward.
If there's no instance of a class, why do you expect the destructor to run? Static member functions don't need an instance of the class to run, which is what you're doing right now. So it won't run at all, because there are no instances to destroy ever.
If you use purely static you have to explicitly create and destroy the static data through static member functions. Try to find a place to do that, whether its [Win|Dll]Main.
All the singleton does is essentially semantic sugar and a little more. You add ::instance() onto every call, but in return the singleton is not actually created unless you need it. However on the other hand you have difficulty controlling when the singleton destroys itself, which is only a problem if you have more than one singleton. With the static classes technique you just destroy them in the correct order.
[edited by - antareus on September 2, 2003 1:38:17 PM]
If you use purely static you have to explicitly create and destroy the static data through static member functions. Try to find a place to do that, whether its [Win|Dll]Main.
All the singleton does is essentially semantic sugar and a little more. You add ::instance() onto every call, but in return the singleton is not actually created unless you need it. However on the other hand you have difficulty controlling when the singleton destroys itself, which is only a problem if you have more than one singleton. With the static classes technique you just destroy them in the correct order.
[edited by - antareus on September 2, 2003 1:38:17 PM]
Author
Cool, thanks
Basically I wanted to see if there was some cheap way to have the class kill itself without me having to call Kill() on it (mainly since it can cause the program to crash if someone forgets to call Kill())
Ah well I''ll just stick w/ Init/Kill. Thanks!
Basically I wanted to see if there was some cheap way to have the class kill itself without me having to call Kill() on it (mainly since it can cause the program to crash if someone forgets to call Kill())
Ah well I''ll just stick w/ Init/Kill. Thanks!
Here''s another thread that might be of interest to you
http://www.gamedev.net/community/forums/topic.asp?topic_id=162401
http://www.gamedev.net/community/forums/topic.asp?topic_id=162401
Making a class with all static methods and properties is the Mono-state idiom, it''s a trivial singleton.
From a design stand-point, the most compelling reason to use a Singleton is to gain polymorphic behavior. For example, a D3DRenderer or a OGLRenderer implementation of the IRenderer interface, which has a special ''gimme-the-singleton'' method.
Somewhere in the code, one thing creates it, and then everyone else uses it, and clean-up is the same for both cases. Or IAlgorithms for which we instance a concrete class optimized for the architecture we''re running on (PIII, P4, AthlonXP, etc).
In C++, the most compelling reason to use a singleton implementation (or perhaps not to use the singleton pattern at all) is to gain a gaurantee over the order of initialization (or avoid this mess altogether). By default, in C++, there is no strict ordering to the initialization of global static''s (in particular different translation units may be initialized in a different order at the compilers whim).
Writing a singleton that provides such gaurantees, in C++, is hard.
From a design stand-point, the most compelling reason to use a Singleton is to gain polymorphic behavior. For example, a D3DRenderer or a OGLRenderer implementation of the IRenderer interface, which has a special ''gimme-the-singleton'' method.
Somewhere in the code, one thing creates it, and then everyone else uses it, and clean-up is the same for both cases. Or IAlgorithms for which we instance a concrete class optimized for the architecture we''re running on (PIII, P4, AthlonXP, etc).
In C++, the most compelling reason to use a singleton implementation (or perhaps not to use the singleton pattern at all) is to gain a gaurantee over the order of initialization (or avoid this mess altogether). By default, in C++, there is no strict ordering to the initialization of global static''s (in particular different translation units may be initialized in a different order at the compilers whim).
Writing a singleton that provides such gaurantees, in C++, is hard.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement