LaurentGomila/SFML — pull request #202 by Oberon00 (2012-04-09 20:16:57+00:00)
Title: Workaround for the default font crash (issue #59)

I've implemented a
# Workaround for the default font crash (issue #59)
It basically defines a static function ```sf::Font::destroyDefaultFont()``` which the user can call to manually (usually at the end of ```main()```) destroy the default font. After destroying the default font, it can be created again by getDefaultFont without doing anything special and calling it more than once or before the font is created does no harm. (Everything tested.)

I dont't think this is the final solution because it requires the user to call a function but it has only a small impact on the codebase and works.

First, I moved the declaration of the default font outside ```getDefaultFont``` in an anonymous namespace, wrapped in a helper struct. To allow calling the destructor manually, I also had to make the font heap allocated / a pointer. The struct is there to ensure that the font gets deleted, even when the user forgets to call the new ```sf::Font::destroyDefaultFont()``` function (so if the user forgets this, the behavior is the same as before). Then I adapted getDefaultFont to the changes (check for ```NULL``` instead of the boolean) and at last I added ```destroyDefaultFont()``` which just deletes the default font and sets the pointer to ```NULL```.

## Pros
+ (Mentioned above:) small impact on both SFML (changes to ```getDefaultFont()``` and a few additions in Font.hpp, .cpp) and user (max. 1 line) code
+ Allows the user optionally to prevent the default font crash manually
+ Does not alter behavior at all, if ```destroyDefaultFont()``` is not called
(especially, if SFML is linked statically it will continue to work just fine, no matter if the function is called).
+ When a real solution to the problem is found, it is easy to make ```destroyDefaultFont()``` a no-op to keep source and even
binary compatibility. Alternatively, a removal of the function only breaks one line of user code (normally ;) )

## Cons
- Theoretical possibility of getting an default-constructed (invalid?) font in case of an out-of-memory situation (i.e. when ```new``` fails), which is currently only detectable by hooking into the ```sf::err()```-stream.