@Nexus: okay so calling destructors lead to undefined behavior (says the 2003 standard) even though it may work.
This sounds like you doubt that the standard is legit or so... 
'Undefined' doesn't mean that the application has to crash or anything, it just means that the standard doesn't say what should happen and thus, anything can happen, from nothing to atomic war. 
It's not only in the 2003 standard but also in the new C++11 standard:
Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended
I totally doubt the standard after which compilers are made, I really do that lol
@eXpl0it3r: I accept that people disagree with me, but opinions should remain opinions and not made into rules or judge upon them if one thing is bad or not (no matter how many think the same way). One knows from the source code what library was used but does not know what external dependencies to the application (.dll files for example) are required. #pragma comment can be encapsulated between #ifdef/#ifndef... #endif statements and use of macros can handle build scripts to some point.
That's your opinion. So are you judging me because I have a diffrent one?
The whole opinion discussion is quite useless, because there's always disagreements which opinion is 'the right' one (even that is again an opinion one can disagree with), so quickly gets into some sort of loop which doesn't really have an end.
The ideas of discussion are then actually to get other people to agree with ones opinions and if both parties don't want to give up their opinion, there's no need for further discussion. But if you want I still can go on and tell you where I've a diffrent opinion and why.
I'm not judging you or anything, dunno from where you got that.
I've tried a few things and came to the conclusion that not declaring any instances of sf::Text doesn't make the application crash on exit for me. I have no idea how sf::Text manages that.
Oh well I've overlooked the 'obvious' part, I think it's once again connected to the ATI/default font bug. There are three posibilities:
- The best solution would be to compile the latest SFML version on your own, because the latest version doesn't provide a default font anymore and you'd be forced to load one on your own.
- Otherwise you can stick to the SFML 2rc but you will have to load your own font directly through the constructor of the sf::Text.
- And if you want to keep the default font, then you'll have to link statically.
Yep default font was it (still rolling with 2.0 RC), fixed now thanks.
