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

Author Topic: [Resolved] Reason for protected sf::VideoResource destructor  (Read 2527 times)

0 Members and 1 Guest are viewing this topic.

quasius

  • Full Member
  • ***
  • Posts: 166
    • View Profile
I was wondering why you chose to make the destructor for sf::VideoResource (already an abstract base-class) non-public.  I added an AlphaMask class derived from VideoResource and wanted to have a container than holds images or AlphaMasks (sf::VideoResource*), but I ran into problems with the protected destructor.
Obviously I could just make the destructor public, but I was wondering why it was protected in the first place, so I don't end up stepping on some other design you have or might have in the future.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
[Resolved] Reason for protected sf::VideoResource destructor
« Reply #1 on: July 05, 2008, 03:06:44 am »
The reason is simple : VideoResource is not meant to be used publicly, so only derived classes should have access to the constructors and destructor.

I can't see any reason to store your variables as VideoResource*, as it doesn't expose any function (using void* wouldn't be worse in this case...). If you do so, you'll have to downcast an instance each time you want to do something with it, which is a very bad design.
Laurent Gomila - SFML developer

quasius

  • Full Member
  • ***
  • Posts: 166
    • View Profile
[Resolved] Reason for protected sf::VideoResource destructor
« Reply #2 on: July 07, 2008, 06:22:43 pm »
Quote from: "Laurent"
The reason is simple : VideoResource is not meant to be used publicly, so only derived classes should have access to the constructors and destructor.

I can't see any reason to store your variables as VideoResource*, as it doesn't expose any function (using void* wouldn't be worse in this case...). If you do so, you'll have to downcast an instance each time you want to do something with it, which is a very bad design.


It was for use in a template class for allocating / recycling objects.  Typing is handled automatically, so having to downcast wouldn't matter and wouldn't be exposed.  Void* wouldn't work with the implementation I have since it has to know what kind of objects to make.
I ended up deciding there wasn't a great reason to combine the AlphaMasks and Images into one allocator anyway other than saving 100 or so bytes for the allocator object.
Thanks for the response.