Messages

1

General / Re: Exception raised on exit. Using singleton with SFML 2.0.

« on: April 13, 2013, 02:30:58 pm »

Thanks eXpl0it3er and Nexus for your advice. I've been using Singletons to speed up the game development process. I realize it's a bad practice, but for the small projects I'm involved in it usually works. Anyway I think now I feel comfortable enough with C++ to find better designs...

Don't quote it out of context. If you search my other posts, you'll find my actual opinion about singletons and global variables.

Sorry, I didn't want to take it as an example of you being supporter of the Singleton pattern. I just wanted to point out that the destroyInstance() in the singleton with global instance was already known in the forums 

If you need input on how to design your code in a better way, don't hesitate to ask.

Thanks! I take your word 

But first I'll think about:

• What components of my code use Singletons
• How do implement such components without using Singletons

before posting anything about it. It's not fair saying "I don't have time to read how to stop using Singletons" and then ask you guys to do the dirty work for me :-)

So far I've found a gold mine! Don't focus on the topic title, but the links there posted. I think the message bus approach can fit my project and will considerably reduce the dependency tree!

2

General / Re: Exception raised on exit. Using singleton with SFML 2.0.

« on: April 13, 2013, 12:22:04 pm »

Anyway, I just Googled in the forums for a solution (Am I the only one who can't search the forums?) and found out this:
program crashes on exit - reply #23

Looks like it's a known practice

3

General / Re: Exception raised on exit. Using singleton with SFML 2.0.

« on: April 13, 2013, 12:12:09 pm »

I've read a lot of discussions (even flame wars) on whether to use Singletons or not. I understand there are reasons against (example) and  for it (example). I didn't want to start with it again 

What I was wondering is that if, assuming I have to use a Singleton for the WindowRendered (or better, without discussing whether that's a good design choice or not), there are better mechanisms for avoiding the "on exit exception".

4

General / Exception raised on exit. Using singleton with SFML 2.0.

« on: April 13, 2013, 12:54:33 am »

Hi there! First post here :-)

I've found this curious situation in which you get an exception on program exit when your main RenderWindow is a static object (in my case is a singleton). The exception is thrown when I close the window and the corresponding stack trace goes like:

   nvoglv64.dll!000000005e1f9b74()   Unknown
   opengl32.dll!000007f967b49ac1()   Unknown
   sfml-window-d-2.dll!sf::priv::WglContext::~WglContext() Line 114   C++
   sfml-window-d-2.dll!sf::priv::WglContext::`scalar deleting destructor'(unsigned int)   C++
   sfml-window-d-2.dll!sf::priv::GlContext::globalCleanup() Line 119   C++
   sfml-window-d-2.dll!sf::GlResource::~GlResource() Line 75   C++
   sfml-window-d-2.dll!sf::Window::~Window() Line 77   C++
   sfml-graphics-d-2.dll!sf::RenderWindow::~RenderWindow() Line 61   C++
   grape++-d.dll!Grape::Application::~Application() Line 49   C++

I'm using SFML 2.0, not from the RC but from the revision a40ef79a18b16fe47ce7eecb7a8d8f6b42b9e5d0 of Feb 21 20:25:11 2013 +0100 compiled with Visual C++ 2012 Express for Desktop to x64 architecture. SFML is linked into a dynamic library, which is also linked (dynamically) to the Application code. The Application is a Windows application (using /SUBSYSTEM:WINDOWS) so its entry point is WinMain, but WinMain just calls a generic int main(int, char**).

I'm not sure, but possibly this exception is related to this other forum thread I didn't want to revive:
Possible Bug in RenderWindow Destructor (SFML 2.0)

I haven't found recent information about this "bug" (inconvenient situation?) so I wanted to ask you how do you avoid it. Also whether it's related to the other forum thread or not. Maybe it's just I'm doing something wrong...

Well, I found an ugly and partial solution. Looks like this happens because SFML deallocates some global resources (OpenGL context?) that can't be postponed to the destructor of a static instance of a class. So I created a destroyInstance() method in my Application singleton that simply deletes the single instance. This prevents the exception on exit.

Relevant code looks like:

// in main.cpp
int main(int argc, char *argv[])
{
        // Application initialization and main loop.
        Grape::Application::instance()->init();
        Grape::Application::instance()->loop();

        // Application destruction before end of main.
        Grape::Application::destroyInstance();
}

// in Application.h
class Application: public sf::RenderWindow
{
public:
        GRAPE_API static boost::shared_ptr<Application> instance(void);
        GRAPE_API static void destroyInstance(void);
private:
        static boost::shared_ptr<Application> sInstance;
};

// in Application.cpp
boost::shared_ptr<Application> Application::sInstance;

boost::shared_ptr<Application> Application::instance(void)
{
        if(!sInstance)
        {
                sInstance = boost::shared_ptr<Application>(new Application());
        }
        return sInstance;
}

void Application::destroyInstance(void)
{
        if(sInstance)
        {
                sInstance.reset();
        }
}
 

What do you think about it? How do you prevent this situation (apart from avoiding singletons and static instances of classes)? Is it really that ugly what I'm doing?

Thanks for your insights! :-D

Álex