sf::Texture don't load

[Qluxzz]

I have a problem when initilizing a class where the texture doesn't load. I have two examples of the problem. One where it works and one where it don't.

// Plane
// Location of the plane's sprite, location of the plane's gun sound, the starting position of the plane, and the health of the plane
playerAircraft player_plane("data/plane/airplane3.png", "data/plane/audio/gun.ogg", sf::Vector2f(250, 400), 100);

The example above works and I can see the plane's sprite. That is the player's plane. I'm using a vector of the class enemyplanes which inherits from the base class airplane. This is the code I'm using to create a new plane.

// Location of the plane's sprite, location of the plane's gun sound, the starting position of the plane, and the health of the plane
enemy.push_back(enemyAircraft("data/plane/airplane3.png", "data/plane/audio/gun.ogg", sf::Vector2f(player_plane.getPlanePosition().x + 200 + rand()% 200, player_plane.getPlanePosition().y), 20));
 

[Ixrec]

The texture and soundbuffer are probably getting destroyed immediately after the push_back.  You have to manage the lifetimes of these objects correctly.  Standard containers always copy the values you give them, and in general it's not safe to copy objects that own external resources like this.

I'm guessing you want to be able to create multiple enemy aircraft objects with the same resources.  If so, one simple solution would be to load the texture and sound early on in main() and then pass pointers to the Texture/Sound objects to each enemyAircraft, so they can all share a single copy of each resource and not worry about accidentally destroying the resources.

Edit: I forgot about the "emplace" functions in C++11.  These might also do the trick for you since they insert without the usual copy.

[Laurent]

If it's a std::vector, even if you avoid the initial copy with emplace_back, the vector can still move all its elements later if it needs more space in memory.

[Ixrec]

I'm aware of two general approaches, and I've used both in my code:

1) Use node-based containers (std::list, std::set, std::map, etc), because the nodes will never get copied once constructed.  You only have the initial insertion copy to deal with, which means either not loading resources in the entity object's default constructor. or using the emplace methods.

2) Use pointers.  Someone else has to actually own the resources, be it main() or some kind of resource management class (note that such a class would use a node-based container), but the entity objects can be safely copied around wherever if their resources are all hiding behind pointers.

If you expect multiple entities to share the same resources, #2 is probably better.