No reason to discourage others here.
If I may give some input:
You could store the texture as a member of the class to preserve it throughout the lifetime of the object. You can load the texture/etc in the constructor but store as a member so it doesn't get freed right after the constructor returns.
I would try something such as having a constructor take the name of the texture's file as an argument, or some other function to set that after object creation. Just keep scope in mind when doing this - once something goes out of scope it will be freed (or a memory leak if not handled properly). Your texture goes out of scope and is thus freed in the code you gave. This could give strange behavior, and most certainly can cause a crash.
class Player
{
public:
Player() = delete; //No default constructor - force the filename to be given
Player(const std::string &filename);
~Player();
//Data members, for later use
sf::Texture m_texture;
sf::Sprite m_sprite;
};
Player::Player(const std::string &filename) {
//do whatever in the constructor
//Load texture, sprite, etc
}
Player::~Player() {
//Do whatever you need to in the destructor
}
That is incomplete, of course, but it's just an example. If you decide to make the members private, you'll have to deal with how to you'll render it. In my projects, for example, I follow the paradigm that anything and everything that needs to be allocated is done so at object creation (with some exceptions, of course). Textures, sprites, shapes, fonts, etc. are kept as members of that class.
I also recommend putting your definitions and declarations in different files (declarations in header files, definitions in cpp files).
But now when you want to render the Player, you can just do
window.draw(p1.m_sprite); //No function call 'm_sprite' is the data member