program crashes on exit

[Nexus]

How are the functions instance() and init() implemented?

Concerning the destructor: Sorry, I got you wrong (I read too vaguely). But do you understand why the code in another function doesn't lead to an error anymore?

[stevend]

yes i do now it was just really early and i havent touched c++ for a few months  :lol:

Code: [Select]

   //! Creates or returns the factory instance
factory * factory::instance()
{
if (!dinstance)
 dinstance = new factory;

return dinstance;
}


Code: [Select]

//! Creates the SFML window and passes off execution
void factory::init (int width, int height, bool fullscr)
{
  window = new sf::RenderWindow(sf::VideoMode(width, height, 32), "2dtile");

  window->UseVerticalSync(true);
  window->SetFramerateLimit(60);
 
  this->StateManager.Init();

  this->GameLoop();
 
}



do you like my engine framework ? im designing a 2d mmorpg. oh noes!

[Laurent]

You never delete your factory instance?

[stevend]

oh right i suppose i should do that too.

i added a unload function to my factory class and i call it in main after the game has finished running and the window has closed.

[Nexus]

Why don't you use the meyers singleton? Very easy, the accessor function creates the instance at first call and destroys it at program shutdown.

Code: [Select]

factory& factory::instance()
{
    static factory inst;
    return inst;
}
Besides, I wouldn't allocate window dynamically. And what if the user forgets to call init()?

[Laurent]

With this kind of singleton you can't control the destruction of the instance, that happens at global exit. This can lead to problems, especially if the singleton contains members that need SFML to be "alive" in order to destroy themselves properly (sf::Image, sf::Font, ...).

[Nexus]

You are right, I didn't think of the dependencies. In this case, a manual call to a cleanup function would be the better alternative. However, one should ensure that the singleton isn't used after destruction (at least by assert).

Or, if this is anyhow possible (and it often is), no singleton at all. As we all know, global variables are evil.

[Laurent]

In this case, a manual call to a cleanup function would be the better alternative

This means using dynamic allocation for these members, in order to be able to destroy them in the function. I think I'd prefer doing so for the whole singleton rather than for its members

[Nexus]

Actually, I meant something similar, a counterpart to the functionality of creating the instance.

Code: [Select]

#ifdef SFML_DEBUG
 #define DEBUG_ONLY(EXPR) EXPR
#else
 #define DEBUG_ONLY(EXPR)
#endif

class Factory
{
    private:
        static Factory* InstancePtr;
DEBUG_ONLY(static bool Destroyed;)

    public:
        static Factory& Instance()
        {
            assert(!Destroyed);
            if (InstancePtr == NULL)
                InstancePtr = new Instance();

            return *InstancePtr;
         }

         static void Cleanup()
         {
             delete InstancePtr;
DEBUG_ONLY(  Destroyed = true;  )
         }
};

Factory* Factory::InstancePtr = NULL;
DEBUG_ONLY(bool Factory::Destroyed = false;)
A check of invalid calls is only performed in debug-mode. There are a lot of tactics, for example the phoenix singleton which recreates the instance if accessed after destruction. Some of them are explained in Modern C++ Design (Andrei Alexandrescu).

Here, I don't think an exception would make much sense because the user can't really react to it. Accessing the singleton after its destruction is a logic error in my opinion, that's why I chose the assertion.