Talk:Singleton pattern

From GPWiki

Qrikko: let me know if I got something wrong here - you created a template for a singleton class, but then ignored it when you created the Keyboard_Listener class from scratch. Is this on purpose? This is a very important subject, but the article is confusing.

I did see youre point there and to be honest I'm not sure what I was trying to show with that, I have edited it a bit, and hopefully its not as confuseing now.

I am new to the wiki, but I think that this game dev. wiki is a great idea and wanted to try out doing a contribution to get a bit more used to how it works.
/Qrikko

Error in "Putting it together"

An anonymous user commented: you missed out implementing the instance() function

Yes, you are absolutely right! I've added that now, thanks for mentioning it! I didn't write this article, I just added the bit about the typedef statement, so I'm not that familiar with the code. Hope it works now. Sion 12:52, 14 Apr 2005 (EDT)

alternative

An alternative approach which is very simple to use, but less 'generic' goes like this:

class Whatever
{
public:
    static Whatever & Instance() { static Whatever; return Whatever; }
    void DoStuff();
private:
    Whatever() {}
    ~Whatever() {}
    Whatever(const Whatever &);
    Whatever & operator=(const Whatever &);
}

and is used as:

Whatever::Instance().DoStuff();

Note that it is impossible for more than one Whatever class to be created, even by accident. To enforce this, operator= and the copy constructor must be declared, otherwise a default implementation will be created for you by the compiler.

Note also that the instance will be created the first time it is used, which means you do have control over the order of construction of different singletons (which might be important). If one singleton uses another, then the order of construction will automatically take care of itself.

This article still seems unfinished, since there are no definitions for the member functions. The "alternative" on this discussion page would work better, imo. --sdw 16:06, 16 February 2006 (EST)

The trouble with that alternative is that you can still run into trouble with lifetimes if two singletons each uses eachother in their destructors, in which case you'd need a pheonix singleton or other fancy lifetime control. Of course, the article's singleton doesn't solve that problem either... --Me22 18:42, 16 February 2006 (EST)

Clarification?

class Keyboard_Listener : public Singleton<Keyboard_Listener>
{
  public:
    void keyPressed(const int key) {m_keys[key] = true;} // sets a key status to pressed
    bool keyPressed(const int key) {return m_keys[key];} // checks a given keys status
 
  private:
    bool m_keys[256]; // not sure how many there are, just a guess
};

Is this what you wanted? --GMan 20:44, 19 May 2006 (EDT)

Implementation?

There needs to be a general description of how to implement the class, and perhaps examples in several languages.

Also, there is some confusion in the article about how the class is instantiated. In one place, it says to call Singleton<T>::Instance(), but in another place it says that the instantiation is automatic. Both are valid implementations, but should differentiated and explained. John Bolton 14:48, 13 August 2006 (EDT)

Misuse of the pattern

The design shown allows for more than one instance of a class and therefore violates the pattern. In code we code do

class Keyboard_Listener
{
  public:
//NOTE constructor is public so many instances can be created
    void keyPressed(const int key) {m_keys[key] = true;} // sets a key status to pressed
    bool isKeyPressed(const int key) {return m_keys[key];} // checks a given keys status
 
  private:
    bool m_keys[256]; // not sure how many there are, just a guess
};
Keyboard_Listener* k( Singleton<Keyboard_Listener>::instance() );
Keyboard_Listener* k1 (new Keyboard_Listener);
k != k1;

!name 2/11/07