Texture Manager, how to make sprites take pointers?

[Notion]

Hey everyone,

What I try to do:
TextureManager.h holds a static pointer to a texture. I want my Sprites, which are basically stored in the class Pic, which are stored in the class Node, which are stored in a vector<Node> to use the texture, to which the texture pointer of my TextureManager points to. For some mysterious reasons its not working. Here are the relevant parts of the code:

//TEXTUREMANAGER.H
#include <SFML/Graphics.hpp>

//Textures
static sf::Texture* nodeTexture;

static void loadTextureSet(int i) {  //called from main method, works properly, can check the correct size after loading
        nodeTexture = new sf::Texture();
        nodeTexture->loadFromFile("Graphics/emptyNode.png");
}

//PIC.H
#pragma once
#include <SFML/Graphics.hpp>



class Pic
{
public:
        Pic( int pathID );
        ~Pic();

        sf::Texture* texture;
        sf::Sprite sprite;

};

//PIC.CPP
#include "Pic.h"
#include <SFML/Graphics.hpp>
#include "TextureManager.h"
Pic::Pic(int pathID)
{
       
        switch (pathID) {
       
        case 0:

                texture = nodeTexture;
                break;
        }
//can successfully call the size of texture until here
        sprite.setTexture(*(texture)); //<- ERROR HERE
//error will occur at the line above this one, cant give out any std::cout here.
}

Is there any way to fix this in an easy way? I know I could use some additional classes and something like the resource manager tutorial, but i would like to keep it really simple and readable.
Error Code is: Exception thrown at 0x00007FFA4C7B6F80 (sfml-graphics-2.dll) in Shattering.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

[Hapax]

SFML resources (and arguably pretty much everything else) should not be in global scope.

[Notion]

Why not? And is this technically a problem or just regarded as bad style for most situations?

[Hapax]

It's considered bad style and can also be considered uncontrollable since you can't be sure when things are actually constructed or destroyed.

As for SFML resources, it has been explained a few times in the forum already although I can't recall the exact details.

[Notion]

Alright, I think its perfectly reasonable in my situation, to use this kind of bad style, since the pointers should exist from the programs start to its termination and should be accessible from everywhere. Therefore doing it this way saves a lot of time passing around references and doesnt really have a downside.

Can someone help me with my problem from the opening post? I really cant figure it out. Much appreciated.

[eXpl0it3r]

It crashes because your pointer is a nullptr (and that probably just because you're running it in debug mode and the memory was zero-padded).

Just because you think that the application flow should run fine, doesn't mean it actually does. Take your debugger and step through your application code. Either the texture never gets created (loadTextureSet not called) or you never assign the texture to the other pointer (no match for the switch-case) or you have left out important code.

And any (experienced) C++ developer will tell you, that's not a reasonable solution to use a global, nor to have it "accessible from anywhere". You do yourself a favor if you pick a design that will be maintainable in the long run, even if your application is just something small, because that's where you get experience from and experience is the key thing in programming - either you have programming experience, or you're a novice (aka newbie).

As for SFML resources, as long as their construction and destruction happens in a non-global scope, it shouldn't crash. Still it's better to use something like Thor's resource holder to manage various types of resources.

[Notion]

It crashes because your pointer is a nullptr (and that probably just because you're running it in debug mode and the memory was zero-padded).

Neither nor. As I told, if i check for  std::cout << texture.size().x; it prints 100, which is the correct size of the png-file. This is possible right before I try to feed the pointer to the sprite. Mentioned that in the comment line as well. Running in Release Mode, checked this already.

Just because you think that the application flow should run fine, doesn't mean it actually does.

Dont mean to sound offensive, but where does this actually come from? Did I state something the like?

or you never assign the texture to the other pointer (no match for the switch-case) or you have left out important code.

As i told, i can cout the size of the thing the pointer points to, so I am _really_ confident about the assignment of that one. Theres a lot of code in the program which I didnt post, since its waaaay to extensive to expect other people to read I guess. But I really cant imagine, which part of it could possibly interfere right between the cout statement and the sprite.setTexture();

[Hapax]

You can retrieve the size of texture after the switch or only before?