Elysian Shadows

dandymcgee wrote:If you're going to implement the Singleton Pattern at least do it correctly.

Or even better, don't do it at all [see: search.php?st=0&sk=t&sd=d&sr=posts&keywords=singleton for reasons]

jaybee wrote:

dandymcgee wrote:If you're going to implement the Singleton Pattern at least do it correctly.

Or even better, don't do it at all [see: search.php?st=0&sk=t&sd=d&sr=posts&keywords=singleton for reasons]

Yeah, I've heard that it isn't a good idea. I know nothing about correctly implementing ANY design patterns. I've looked into it a bit but a lot of times the examples are too complicated or so conceptual that I'm not able to figure out how to apply it to my projects.

What exactly is incorrect about an object with a static instance of itself?

class Singleton {
public:
    static Singleton& instance();

private:
    Singleton();

    // These declarations ensure that the
    // Singleton class is non-copyable.
    // Attempting to copy through a
    // copy-constructor or assignment
    // operator will result in compiler errors
    // (due to the private declarations) for
    // client code and linker errors for
    // Singleton implementation code (due to
    // these declarations not being defined).
    //
    // In C++11, these would be marked =delete.
    Singleton(const Singleton&);
    Singleton& operator =(const Singleton&);
};

Singleton& Singleton::instance()
{
    static Singleton inst;
    return inst;
}

Singleton::Singleton()
{
    // By using a private constructor, you ensure that
    // the class may only be instantiated within itself.
    // In this case, it is not possible to instantiate a
    // Singleton in client code, so the only Singleton
    // instance in the entire program is the one
    // instantiated in the Singleton::instance() function.
}

Nokurn wrote: The order in which global objects (such as an instance static) are initialized is not guaranteed. You may have a singleton that depends on another singleton, but the dependent singleton is initialized first. By using lazy evaluated singletons, you ensure that singletons are initialized in the proper order (at least, in single-threaded code). It also guarantees destruction.

Nokurn wrote: If your code is single-threaded, the correct way to go about implementing a singleton goes something like this:

class Singleton {
public:
    static Singleton& instance();

private:
    Singleton();

    // These declarations ensure that the
    // Singleton class is non-copyable.
    // Attempting to copy through a
    // copy-constructor or assignment
    // operator will result in compiler errors
    // (due to the private declarations) for
    // client code and linker errors for
    // Singleton implementation code (due to
    // these declarations not being defined).
    //
    // In C++11, these would be marked =delete.
    Singleton(const Singleton&);
    Singleton& operator =(const Singleton&);
};

Singleton& Singleton::instance()
{
    static Singleton inst;
    return inst;
}

Singleton::Singleton()
{
    // By using a private constructor, you ensure that
    // the class may only be instantiated within itself.
    // In this case, it is not possible to instantiate a
    // Singleton in client code, so the only Singleton
    // instance in the entire program is the one
    // instantiated in the Singleton::instance() function.
}

Nokurn wrote: As for your destructor problem, place debug prints around each for_each loop to help narrow it down. Unless sf::Music::stop() is the source of the issue, I suspect that your Deallocator functors are the problem.

Nokurn wrote: Edit: I would like to include my recommendation against using a singleton. I would advise the use of individual sound managers that store related pools of sounds and directly passing the managers to their users. This would allow you to implement more fine-grained control of resources; you could have a pool of sounds that must be available for the duration of the program's execution and pools that exist only for a particular level's lifetime, which are destroyed when the level is completed.

jaybee wrote:I'm not sure how sfml handles music internally and if it even really matters if I delete the sound without stopping it. I'm not getting any errors so I assume its ok.

jaybee wrote:I know there is a good reason for not using singletons and globally available objects but I am just missing it. I would imagine understanding that peice of the puzzle is the key for me to start designing better code. Can you point me in the direction of some design patterns that would be beneficial for me to start studying?

• Resource acquisition is initialization (RAII)
• The bridge pattern (also known as the Pimpl idiom)
• The observer pattern (known as signals/slots in Qt, events/delegates in C#)
• The curiously recurring template pattern (CRTP; I would strongly recommend reading this if you write any substantial amount of template code)
• The single responsibility principle (SRP; one of the most important)
• The "don't repeat yourself" principle (DRY; another important one)
• The "keep it simple, stupid" principle (KISS; also important)

jaybee wrote:I know there is a good reason for not using singletons and globally available objects but I am just missing it. I would imagine understanding that peice of the puzzle is the key for me to start designing better code. Can you point me in the direction of some design patterns that would be beneficial for me to start studying?

Falco Girgis wrote:At first it seems like an incredibly easy and versatile way to access data from anywhere, but once your code-base grows, being able to pull references to objects out of your asshole at an point during execution becomes an untraceable mess.

jaybee wrote:Sometimes I've wondered if I should just go about my business coding like a dumbass if for no other reason than to fall flat on my face and understand how my implementation fails.

Falco Girgis wrote: I discussed a pretty useful alternative to the Singleton design pattern that we use here:
http://elysianshadows.com/phpBB3/viewto ... ton#p82674

jaybee wrote:

Falco Girgis wrote: I discussed a pretty useful alternative to the Singleton design pattern that we use here:
http://elysianshadows.com/phpBB3/viewto ... ton#p82674

Shit dude I just went back and read this thread one more time and I just got your point. That's pretty slick. In my case, dealing with a sound manager, almost everything needs to make sound, even things that are already inhereting from a base class. How do you keep things from getting out of hand with situations like that?

Lets say I've got a GameObject class and a Character class that inherits from it. Would I simply make GameObject inherit from SoundManager to avoid multiple inheritance hell?

Falco Girgis wrote:

jaybee wrote:

Falco Girgis wrote: I discussed a pretty useful alternative to the Singleton design pattern that we use here:
http://elysianshadows.com/phpBB3/viewto ... ton#p82674

Shit dude I just went back and read this thread one more time and I just got your point. That's pretty slick. In my case, dealing with a sound manager, almost everything needs to make sound, even things that are already inhereting from a base class. How do you keep things from getting out of hand with situations like that?

Lets say I've got a GameObject class and a Character class that inherits from it. Would I simply make GameObject inherit from SoundManager to avoid multiple inheritance hell?

Yeah, that's what I would do, provided almost every GameObject needs access to the SoundSystem pointer or whatever.

              GameObject
       |                         |
SoundObject : SoundManager   SilentObject