Overview of Virtual Functions - Virtual versus Pure Virtual
(Page 3 of 5 )
Now the obvious question comes up as to when to use virtual functions and when to go down the pure virtual road. Virtual functions are already defined in the base class; because of this, they offer a default implementation.
Suppose you have a collection of derived classes, and a vast majority of them should react in the same manner over a function call. It is a good idea to make the function virtual, so you do not have to write that down repeatedly. The virtual function will be automatically inherited, unless you overwrite it.
Then again, with the pure virtual function you can avoid the existence of an invalid function/object at a level. As you can see from the previous page, a GeEntity cannot be drawn on the screen, and if we make the draw function a pure virtual, we will assure that we will have only base pointers pointing to derived class objects -- because if you try to declare an abstract class, that will cause an error to be thrown at build time.
Still, make sure that all of the derived classes will have the function before you use the pure specification. The abstract classes offer a public interface for the base classes rather than a real object. With them, you practically say to the compiler, "trust me, there will be a function present when you call it from the base pointer."
With an abstract class, pointers and references are possible, so we can take advantage of the polymorphic traits of OOP. Inside an abstract class, you can have as many pure virtual functions as you want, and the members and functions that exist are subject to the inheritance rules. In addition, the class's constructor is called when you declare one of the base classes; it's just that on its own, it cannot exist.
This scheme allows the programmers to form a layered software system. A perfect example is drivers for operating systems. In our hectic society there are countless devices that all can operate in their own ways. Yet many of the functions used have a certain level of resonance, like their read/write functions.
It is up to each device as to how it will manipulate the written message that comes in. Maybe it will print a dark picture on the screen, or just start to play the MP3 player you have attached to the computer. Nevertheless, in the midst of all this, the write procedure, from the point of view of the OS, is no different for any driver; it simply places a few bytes of data here and there.
If you are planning an OOP-oriented OS, this may provide a public interface for all drivers. Then you can leave for the drivers a collection of public virtual (pure virtual) functions that they can just overwrite in order to interpret the data as they want. Now, if you plug in a new device and provide its new driver (a derived object from the public interface), the OS can communicate with the new device even if, at the time the OS was made, the device was not even in the planning stages.
Next: Virtual Deconstructor >>
More C++ Articles
More By Gabor Bernat
