Curious question about static array of sf::Texture(s), not working.

[Moonkis]

#include "TextureLocator.hpp"

sf::Texture TextureLocator::textures[TIDS::UNIQUE_TIDS] = {sf::Texture()};

bool TextureLocator::init() {
        TextureLocator::textures[TIDS::PLAYER].create(5,5);
        TextureLocator::textures[TIDS::BULLET].create(1,1);
        TextureLocator::textures[TIDS::ENEMY].create(4,4);
        TextureLocator::textures[TIDS::EXPLOSION].create(16,16);
        return true;
}

sf::Texture& TextureLocator::get(TIDS id) {
        return textures[id];
}
 

I get a runtime error, why? Isn't this legal?

First-chance exception at 0x779422D2 (ntdll.dll) in Leklåda.exe: 0xC0000005: Access violation writing location 0x00000004.
Unhandled exception at 0x779422D2 (ntdll.dll) in Leklåda.exe: 0xC0000005: Access violation writing location 0x00000004.

These are the errors I get. I think they are related to initializing the static array in the .cpp file above. Feels pretty weird to me. Anyone want to shine some light on this.

Here is the callstack as well:

   ntdll.dll!779422d2()   Unknown
    [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]   
    Leklåda.exe!sf::priv::MutexImpl::lock(void)   Unknown
    Leklåda.exe!sf::Mutex::lock(void)   Unknown
    Leklåda.exe!sf::Lock::Lock(class sf::Mutex &)   Unknown
    Leklåda.exe!sf::GlResource::GlResource(void)   Unknown
    Leklåda.exe!sf::Texture::Texture(void)   Unknown
>   Leklåda.exe!`dynamic initializer for 'TextureLocator::textures''() Line 3   C++
    msvcr110d.dll!_initterm(void (void) * * pfbegin, void (void) * * pfend) Line 889   C
    Leklåda.exe!__tmainCRTStartup() Line 460   C
    Leklåda.exe!mainCRTStartup() Line 377   C
    kernel32.dll!75a2336a()   Unknown
    ntdll.dll!77959f72()   Unknown
    ntdll.dll!77959f45()   Unknown

[Ixrec]

I think you aren't allocating memory for those textures.  Remember that create() is not the constructor.

[Laurent]

sf::Texture instances cannot be declared at global scope, because they may be constructed before SFML internal globals, and thus result in such a crash. This applies to all resource classes, and as a general rule you should avoid globals anyway