Static Linking Crash Error

[DxE]

In response to the original thread's author wanting a new thread for my issue I've made this, mods can nuke posts or whatever in the other thread if they wish to keep it clean. All the information I can think of giving is below:

I set up a second, smaller and simpler program in VS2013 with the debug build set up to statically link and the release build to dynamically link and both work... Most of the time.

With the following code:

(click to show/hide)

#include <SFML/Graphics.hpp>

sf::RenderWindow window;

int main(int argc, char** argv){
        //if sf::RenderWindow window is here instead, then the code runs fine regardless of linker setup
        window.create(sf::VideoMode(300, 300), "Static Linking Test");

        sf::CircleShape circle(100, 50);
        circle.setPosition(50, 50);
        circle.setFillColor(sf::Color(0, 255, 0));

        while (window.isOpen()){
                sf::Event event;
                while (window.pollEvent(event)){
                        if (event.type == sf::Event::Closed){
                                window.close();
                        }
                }

                window.clear();
                window.draw(circle);
                window.display();
        }

        window.close();
        return 0;
}

This happens with the Debug (statically linked) build: http://puu.sh/9c2Eo.png
This happens with the Release (dynamically linked) build: http://puu.sh/9c2T4.png

The following images are of my settings in the Debug build configuration:
Directories: http://puu.sh/9c2W9.png
Pre-Processor: http://puu.sh/9c2Yc.png
Code Generation: http://puu.sh/9c2ZH.png
Linker Input: http://puu.sh/9c32l.png

Does this just mean I haven't compiled SFML correctly, or is there a flaw in my linker settings?

[Jesper Juhl]

Why are you closing the window after the while loop?
The loop only runs while the window is open, so closing it after the loop when you know that it can't possibly be open any more is a bit pointless.

Why is the window global?
Global variables are a bad idea in general And global sfml objects are a very bad idea specifically - don't do that.

[DxE]

Ahh, force of habit on the window.close() at the end there; usually I'm using a variable in the while loop instead of window.isOpen(), the fact that the program closes when I open it leads me to believe this doesn't effect the issue (and I suspect window.close() checks whether or not the window is actually open before trying to do whatever it is going to do anyway).

I've never had any issues with a global sf::RenderWindow in the past but from the tone of your reply I suspect it's bad enough that it could potentially be the cause of my issue? If so, is there an explanation that you can either give or link me to on why global SFML objects in particular are worse than others?

[Nexus]

Global variables are bad, because they decrease modularity and increase dependencies. In particular, it's more difficult to control the access and to keep side effects local, which makes maintenance and debugging more annoying. For multithreaded scenarios, concurrent access is another problem and makes it necessary to synchronize access, increasing complexity and leading to worse performance. Initialization and destruction order is yet another issue, in particular for SFML classes that depend on each other.

Don't use global or static variables. They come at a much higher cost than you'd initially think. Most well-designed C++ applications can avoid them (with the exception of a few centralized parts like logging). Don't use lazyness as an excuse to not think about good design -- the time is well-invested.

[Jesper Juhl]

Nexus said it better than I could. But let me add a few sentences.

Nexus' points about global variables leading to too tight coupling I agree with 100%.
The main problems with SFML objects as global variables are; the fact that various SFML classes have inter-dependencies and you want to be in control of their construction/destruction order - which you lose with global variables (construction/destruction order of globals is only guaranteed within a single compilation unit).
Globals also have the problem that they are constructed before entering main and destroyed after main is done, which limits a few things about what they can assume about the world - may be corner cases, but if you don't know the classes are safe in those contexts then don't assume they are.

Don't know if you are considering "Singletons" as an alternative. But if you do I want to say: don't. Singletons are just as much global variables as anything else and have all the same (and more) problems. They are an anti-pattern. Stay away from them.