SFML community forums
Help => General => Topic started by: quasius on July 04, 2008, 04:32:36 pm
-
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.
-
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.
-
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.