Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Hazelnuss

questions on singleton templates

This topic is 5652 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want to write a singleton template for my managers, but which singleton pattern should i use? Pointers or just a static instance in the Get-method? Which one do you use? What are the pros and the contras? [edited by - Hazelnuss on June 19, 2003 2:53:29 PM]

Share this post


Link to post
Share on other sites
Advertisement
Using a static instance you can''t control when it is created. Using a pointer that is initialized to null and then newed on the first request for the object, you can control exactly when it is created.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Extrarius
Using a static instance you can''t control when it is created. Using a pointer that is initialized to null and then newed on the first request for the object, you can control exactly when it is created.

Meyer''s singleton solves that:

Instance& getInstance() {
static Instance instance;
return instance;
}
Tadah. Created when first used. That''s what Hazelnuss meant by "static instance *in* the Get-method"

Share this post


Link to post
Share on other sites
Yeah i like that one better because you can''t forget to call the Destroy-method. So, i could use that one for my managers without having to fear to encounter any strange program crashes caused by singleton usage?

Share this post


Link to post
Share on other sites
Have a look at Loki. One of the things it provides is a framework for singletons.

- Magmai Kai Holmlor

"No, his mind is not for rent to any god nor government" - Rush, Tom Sawyer

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows| Spirit(xBNF)]
[Free C Libraries | zlib ]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Hazelnuss
So, i could use that one for my managers without having to fear to encounter any strange program crashes caused by singleton usage?
No. You would have to make sure that singleton destructors don''t use other singletons, because they are destructed in arbitrary order. If a Logger singleton is destructed before World singleton and World''s destructor uses Logger, then you''ll get a strange program crash. Loki''s singleton has an implementation ("policy" called "phoenix singleton" that prevents this from happening (it recreates a singleton that has been destroyed).

I''d like say that don''t use singletons at all.. But since it''s your job, I take it you have to do one.

Share this post


Link to post
Share on other sites
Avoid them as much as possible. If you need more than one then make the top level singleton control the others lifetimes.

Share this post


Link to post
Share on other sites
I have a couple of game state classes and most of them need to be able to access those managers. Where else should i store them then? In the main app class and make them accessible via some Get-methods? Why should I avoid singletons anyway? They seemed really useful to me thus far...

Share this post


Link to post
Share on other sites
This is my personal favorite singleton pattern:


#include <cassert>


template<typename _Derived>
class Singleton
{
static _Derived* sInstance;
public:
Singleton()
{
assert(sInstance==0 && "Singleton already exists!");
sInstance = static_cast<_Derived*>(this);
}
~Singleton()
{
assert(sInstance!=0 && "Destroying non-existant singleton.");
sInstance = 0;
}
static _Derived& GetInstance()
{
assert(sInstance!=0 && "Accessing non-existant singleton.");
return *sInstance;
}
};


And this is how I use it:


#include "singleton.h"

class Game : public Singleton<Game>
{
public:
// blah blah

};
#define gGame Game::GetInstance()


That way, I have complete explicit control over the singleton object''s lifetime.

If I have multiple singletons, and I need to make sure they''re constructed in a specific order, I usually just declare the objects themselves in the right order, right at the top of the entry point of the application (main()/WinMain()). And then those objects are accessible no matter where you are in the program''s execution. And when the main() function exits, they''ll be destructed in a deterministic order.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Hazelnuss
Why should I avoid singletons anyway? They seemed really useful to me thus far...
Singletons increase coupling a *lot*. After all, they can be accessed in arbitrary places throughout your application. And when using singletons, you can''t have multiple object hierarchies. Think of adding a multiplayer feature to a game. Then multiple World-classes and Logger-classes would be necessary.

Singleton is a hack. It may enable you to prototype faster, but it will bite you in the ass later if (or when) you keep extending your application.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!