Jump to content
  • Advertisement

Archived

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

wild_pointer

singletons

This topic is 5715 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

Is there anything wrong with something like this:
        
template <class T>
class singleton {
private:
    singleton();
    ~singleton();

    static T &get_instance( void );
};

T &singleton< T >::get_instance( void )
{
    static T instance;
    return instance;
}
        
I mean, it seems to work, but I didn't know if i violated some rule I can't think of, and will bite me in the ass later. I also remember alot of good discussion on singletons here a while back that i can't seem to dig up, so comments are welcome.
[My site|SGI STL|Bjarne FAQ|C++ FAQ Lite|MSDN|Jargon]
Ripped off from various people [edited by - wild_pointer on November 21, 2002 5:30:18 PM] [edited by - wild_pointer on November 21, 2002 6:01:48 PM]

Share this post


Link to post
Share on other sites
Advertisement
Singleton's get_instance probably should be public, eh?-)

typedef singleton<Foo> FooSingleton;

There are things to consider:
-Foo is the class where you must make constructors private so that outsiders can't create more instances of it
-still, singleton must be able to access Foo's constructor, so you must make it a friend class
-be warned that the instance is created when first invoked, and destructed in reverse order.. So, during program shutdown, some destructors might be calling a singleton that has already been destroyed

[edited by - civguy on November 21, 2002 6:15:39 PM]

Share this post


Link to post
Share on other sites
Most singletons I''ve seen return a pointer to the singleton. This makes it impossible to mistakenly duplicate the object.


Share this post


Link to post
Share on other sites
Actually, I'm pretty sure that isn't truly considered a singleton, though I could just be talking about a particular type of singleton, I'm not sure of the actual "definition" of a singleton, or if there actually is one.

Usually what you'd do is not have a static instance of the object but instead, you have a static pointer to an object that is actually used for dynamic allocation and de-allocation. The programmer explicitly calls a function to construct and one to destruct the object and the class keeps track of whether or not the class is currently initialized.

The reason for that is order of construction. Say you have two objects where one objects construction relies on the initialized version of the other. If the two objects were in separate files, etc. it would be hard to be sure of the order of their construction and destruction. Just making a static instance as you did in your example without isn't really solving that problem.

Once again, what I may be talking about could be a specific type of Singleton, I'm not sure, though this is the only type that I use. I believe that there is a name for what you are doing and I think it's a "monotype," which is not the same thing as a singleton, but I could be mistaken. I'm sure someone can give you a flat out definition if there is one.

[edited by - Matt Calabrese on November 21, 2002 10:57:47 PM]

Share this post


Link to post
Share on other sites
OK, every post here is focusing on some aspect of a singleton (not counting the wrong posts), but none are explaining ...

singleton is a design pattern, with multiple rules, each for various reasons ... there are various partial singleton ideas that have valid uses as well ...

a singleton is a class that A) can only have one instance, period - and B) the instance is globally accesable.

those are the only rules, and anything which follows those rules is a singleton ... now in the real world there are extra issues(such as initialization and shutdown order) to be dealt with.

I have similar templates to yours, but find that there is not any one singleton implementation which works for all singletons, and here are some reasons why (aka issues and tradeoffs)

1. Sometimes you want a singleton to be self managing (ie not need explicit construction / descruction) hence you do what you did with the static member function memeber - which create the item automatically at first call, and destroys it upon program shutdown.

2. Almost always you want a singleton to have private constructors and descrutors, so that it, not the caller, can control it''s lifetime ...

3. Often a singleton will need information at construction time, or need to destroyed in a specific order, so liftimes must be managed somehow.

In your example, you offer extra feature #1, but not #3 (the 2 are pretty much mutually excusive) ... and #2 is really a rule of singletons, that there CAN ONLY BE ONE instance ever, and you do not satisfy that rule for type T ...

There are multiple ways to implement singletons -

1 - (like yours), you make a template which will be the singleton class, which accepts type T which must be a special class which meets the needs of the template (private construtor / destructor, friends of template, etc). This system is not theortically correct, because you can make singleton of int and it would obviously not be enforcing the singleton rule, but compile just fine.

So you see, the problem with your singleton is just that it ensure IT is only instantiated once, but not the type T.

This is not a singleton then, it''s an improved global variable (a singleton without the rules is a global variable) - the reason this is improved, is because access is through a function, and therefore can be changed latter without requiring changes to your clients ...

I use the same thing for my logging classes, where i have logging classes (like DualFileLogManager, and NetworkLogManager), and I have a singleton class called SystemLog which provides the central static access function to a log manager, AND wraps it in semaphore so it''s thread safe ... all preventing the underlying manager classes from being instantiates seperately ... this way there is ALWAYS a system log, just like a singleton, and it''s thread safe ... but you can make other special purpose logs anytime you want, and the thread safety for them is up to you ...

Share this post


Link to post
Share on other sites
quote:
Original post by wild_pointer
What are the drawbacks and what do you recommend instead?
Well, since singletons are accessible anywhere, they complicate your design. If you make a class singleton, then that classes' management isn't necessarily centered in one logical part of your program, but scattered throughout the whole program. You can always pass objects around as parameters, so singleton is usually nothing but a convenient way to get rid of that workload. (it also enforces one instance, which may be needed at times)

This convenience isn't always a bad thing though - we're humans after all. I'd use singleton for object factories, for example. Just don't go using that pattern too merrily or it does bite you in the ass eventually, no matter how well implemented.

[edited by - civguy on November 22, 2002 3:31:52 AM]

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!