Hi,
Is there a good rule of thumb when to use a virtual function, a typical case or scenario? I understand what they do, but at this stage it's a bit hard to immediately see when it's a good choice.
Printable View
Hi,
Is there a good rule of thumb when to use a virtual function, a typical case or scenario? I understand what they do, but at this stage it's a bit hard to immediately see when it's a good choice.
Virtual functions are very useful for overriding behavior specific to a derived type. I say overriding here so as not to confuse it with overloading. For instance if we create a base class Vehicle and create a virtual function called Accelerate() then various derived types of Vehicles can implement accelerate in any way they want. Virtual functions do not have to exist in the derived class - in other words if the function is implemented in the base then the derived class is not forced to implement the function.
In the case of pure virtual functions these are used to create interfaces whereby object implement said interface differently but the outward interface does not change. This means that the code using the interface does not change yet behavior behind the interface can still change without ever modifying the code using the interface. It is very handy for DLLs. Programming to an interface is much simpler and more straightforward than programming to an implementation and, in the end, the interface approach nearly always has better design behind it. Pure virtual functions must be implemented in the derived object or the code will not compile.
Note that you can actually have a pure virtual function with a default implementation even though I have never seen a use for it as of yet.
You may have a base class that should be an abstract base class, but none of the virtual functions are suitable to be declared pure virtual. As such, you declare the destructor as pure virtual, but still implement it.Quote:
Originally Posted by Bubba
Thanks Bubba, great explanation. It seems like virtual functions would almost always be preferred, I guess there is some tiny overhead associated with them. Would you normally chose the simple static binding when you sure the extra flexibility isn't needed then.
Always be preferred? I hope, you are not going to mark every function as virtual, aren't you? Otherwise they WILL make an overhead (maybe even huge) as neither of them will be expanded inline (unless the variable is not a pointer/reference, which happens quite rarely - there might be some other exceptions).Quote:
Originally Posted by Subsonics
And what do you mean with extra flexibility? I mark functions virtual only if there is such a need.
Strictly based on the features described, it seems better to have the option than not. Not taking into account any potential overhead, as I mentioned. I bet it's not that huge either, looking up an address in a v-table or go straight to the address. What do you mean by the inline expansion?Quote:
Originally Posted by kmdv
Most of the methods I write do not need to be virtual and will never be, so why do you want to bother with obfuscating and degenerating your code?Quote:
Originally Posted by Subsonics
I mean, if the function is marked as virtual, it will not be expanded inline (in most cases).
But that is what I said, "if you are sure you don't need it". The difference as I see it is wether the function pointer is known at compile time or not. Declaring something as "virtual inline" sounds like an oxymoron, although possible apparently.Quote:
Originally Posted by kmdv