Jump to content
  • Advertisement
Sign in to follow this  
caldiar

Header Files & Virtual Functions

This topic is 4189 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I just hooked my computer back up after a few months since I'm moving. I haven't moved yet but I was getting impatient and wanted my computer back. Anyways, I opened up some old code I was writing and when I looked at a few files I had a wtf moment. The files are organized like this: Header Folder - Renderer: Manager.h Graphic_Manager.h Texture_Manager.h Geometry_Manager.h Model_Manager.h Source Folder - Renderer: Graphic_Manager.cpp Texture_Manager.cpp Geometry_Manager.cpp Model_Manager.cpp Now, I looked at the Manager.h file and in short its just some simple basic functions like Load(), Unload(), Purge(), Init(), etc.... and they're all virtual. Ok, no big deal. But I take a look at the rest of the _Manager.h files and they derive themselves from the Manager.h file with all the virtual functions. I say to myself "That's kinda silly. Manager.h doesn't actually do anything. It doesn't actually execute any functions. It doesn't manage anything. So why inherit from it?" There's really no point in inheriting from virtual functions when the virtual functions don't even do anything. I don't need to make the child classes behave differently than the parent because the parent doesn't even have any functionality! I figure I could just get rid of Manager.h and have all of the other classes just be parents. The reason I'm posting this is because I fail to see what possible reason I could have for even writing the files like this. If anybody might actually see some reasoning to my thought process I would appreciate hearing it. I'm having a hard time getting back into the groove of programming. =( Thanks for taking the time to read this. I look forward to hearing back from you.

Share this post


Link to post
Share on other sites
Advertisement
The base class provides a common interface, which can be used by other functions to manipulate the objects. For instance, you might want to implement:

void UnloadAll(Manager & m, std::list<std::string> resources) 
{
for(std::list<std::string>::iterator it = resources.begin();
it != resources.end(); ++it)
{
m.Unload(*it);
}
}


This has the advantage of being usable for any manager. Of course, unless you actually need several different objects to be usable by another in this way, don't add a base class.

Share this post


Link to post
Share on other sites
Oh! Thank you so much ToohrVyk! I vaguely remember the reason for doing it the way that I was. Maybe now I can work my way back into that programming groove ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!