||This article needs additional citations for verification. (March 2013)|
|Theories and practice of polymorphism|
In object-oriented programming, a virtual function or virtual method is a function or method whose behavior can be overridden within an inheriting class by a function with the same signature. This concept is a very important part of the polymorphism portion of object-oriented programming (OOP).
The concept of the virtual function solves the following problem:
In OOP when a derived class inherits from a base class, an object of the derived class may be referred to via a pointer or reference of either the base class type or the derived class type. If there are base class methods overridden by the derived class, the method actually called by such a reference or pointer can be bound either 'early' (by the compiler), according to the declared type of the pointer or reference, or 'late' (i.e. by the runtime system of the language), according to the actual type of the object referred to.
Virtual functions are resolved 'late'. If the function in question is 'virtual' in the base class, the most-derived class's implementation of the function is called according to the actual type of the object referred to, regardless of the declared type of the pointer or reference. If it is not 'virtual', the method is resolved 'early' and the function called is selected according to the declared type of the pointer or reference.
Virtual functions allow a program to call methods that don't necessarily even exist at the moment the code is compiled.
In C++, virtual methods are declared by prepending the virtual keyword to the function's declaration in the base class. This modifier is inherited by all implementations of that method in derived classes, meaning that they can continue to over-ride each other and be late-bound.
For example, a base class
Animal could have a virtual function
Fish would implement
eat() differently than subclass
Wolf, but one can invoke
eat() on any class instance referred to as Animal, and get the
eat() behavior of the specific subclass.
This allows a programmer to process a list of objects of class
Animal, telling each in turn to eat (by calling
eat()), without needing to know what kind of animal may be in the list, how each animal eats, or what the complete set of possible animal types might be.
Abstract classes and pure virtual functions 
A pure virtual function or pure virtual method is a virtual function that is required to be implemented by a derived class, if that class is not abstract. Classes containing pure virtual methods are termed "abstract"; they cannot be instantiated directly. A subclass of an abstract class can only be instantiated directly if all inherited pure virtual methods have been implemented by that class or a parent class. Pure virtual methods typically have a declaration (signature) and no definition (implementation).
As an example, an abstract base class
MathSymbol may provide a pure virtual function
doOperation(), and derived classes
doOperation() to provide concrete implementations. Implementing
doOperation() would not make sense in the
MathSymbol class, as
MathSymbol is an abstract concept whose behaviour is defined solely for each given kind (subclass) of
MathSymbol. Similarly, a given subclass of
MathSymbol would not be complete without an implementation of
Although pure virtual methods typically have no implementation in the class that declares them, pure virtual methods in C++ are permitted to contain an implementation in their declaring class, providing fallback or default behaviour that a derived class can delegate to, if appropriate.
Pure virtual functions can also be used where the method declarations are being used to define an interface - similar to what the interface keyword in Java explicitly specifies. In such a use, derived classes will supply all implementations. In such a design pattern, the abstract class which serves as an interface will contain only pure virtual functions, but no data members or ordinary methods. In C++, using such purely abstract classes as interfaces works because C++ supports multiple inheritance. However, because many OO languages do not support multiple inheritance, they often provide a separate interface mechanism. An example is the Java programming language.
Behavior during construction and destruction 
Languages differ in their behavior while the constructor or destructor of an object is running. For some languages, notably C++, the virtual dispatching mechanism has different semantics during construction and destruction of an object. While it is recommended that virtual function calls in constructors should be avoided for C++, in some other languages, for example C# and Java, the derived implementation can be called during construction and design patterns such as the Abstract Factory Pattern actively promote this usage in languages supporting the ability.
Virtual destructors 
Object-oriented languages typically manage memory allocation and deallocation automatically when objects are created and destroyed. However, some object-oriented languages allow a custom destructor method to be implemented, if desired. If the language in question uses automatic memory management, the custom destructor (generally called a finalizer in this context) that is called is certain to be the appropriate one for the object in question. For example, if an object of type Wolf that inherits Animal is created, and both have custom destructors, the one called will be the one declared in Wolf.
In manual memory management contexts, the situation can be more complex, particularly as relates to static dispatch. If an object of type Wolf is created but pointed to by an Animal pointer, and it is this Animal pointer type that is deleted, the destructor called may actually be the one defined for Animal and not the one for Wolf, unless the destructor is virtual. This is particularly the case with C++, where the behavior is a common source of programming errors.
While it might seem as though non-virtual destructor behavior is never the right thing, in very memory- or CPU-constricted environments where the overhead of polymorphism is not desired, and where objects are never deleted polymorphically, avoiding the construction of a virtual function table may be considered[by whom?] a worthwhile optimization.
See also 
- Meyers, Scott (June 6, 2005). "Never Call Virtual Functions during Construction or Destruction".