Virtual Destructors?

[Hiura]

If you mean using private inheritance like aggregation then it is also wrong in this case. Herb Sutter has an article here that illustrates with a similar example why it is not a good practice to use it.

[Mario]

I'm usually just doing something like this (written from memory and simplified; so might contain errors):

std::map<const std::string, std::unique_ptr<sf::Texture> > texstorage; // this stores all textures

sf::Texture &getTexture(const char *file) {
    std::map<const std::string, std::unique_ptr<sf::Texture> >::iterator a = texstorage.find(file);

    if (a != texstorage.end()) // texture has been loaded before
        return *a->second->get(); // return the old texture

    sf::Texture *tex = new sf::Texture(); // create a new texture
    tex->loadFromFile(file); // load the image

    texstorage.insert(std::make_pair(file, std::unique_ptr<sf::Texture>(tex))); // save it for later
    return *tex; // return the new texture
}
 

Just make sure to empty the map before your context is destroyed.

[joshua1984]

It makes a lot more sense to inherit from a Texture than to "contain" it and then duplicate its entire API. Seriously, the destructors should just be virtual. How much of a performance hit could it possibly be? And this is not trying to anticipate every possible situation--it's trying to anticipate the most basic, common of requirements.

If you inherit from sf::Texture, then you have to keep the derived type in order to use the extra functions, which means that there's no polymorphism and no issue with the destructor.

But anyway, this is really not the right design. Look at some other popular C++ libraries, can you find one where all the destructors are virtual?

Theres a reason we use sfml over other libraries

[FRex]

Irrlicht ,but everything there is interface class to underlying graphics API(of which there are 5 and null) or to allow customization.