Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Virtual Destructors?  (Read 8181 times)

0 Members and 1 Guest are viewing this topic.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Virtual Destructors?
« Reply #15 on: June 07, 2013, 12:35:48 am »
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.
SFML / OS X developer

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 878
    • View Profile
Re: Virtual Destructors?
« Reply #16 on: June 10, 2013, 10:16:41 am »
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

  • Newbie
  • *
  • Posts: 13
    • View Profile
Re: Virtual Destructors?
« Reply #17 on: July 19, 2013, 02:55:32 am »
Quote
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

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Virtual Destructors?
« Reply #18 on: July 19, 2013, 03:21:02 am »
Irrlicht ;D ,but everything there is interface class to underlying graphics API(of which there are 5 and null) or to allow customization.
Back to C++ gamedev with SFML in May 2023