The concept of a
virtual function is found in virtually every
object-oriented programming language. Only methods on an object can be virtual, free-floating functions cannot.
In older, compiled languages such as C++ or Delphi that have significant pre-OO baggage, it is usually the case that only functions that are explictily declared as virtual are such, and the rest are not.
In more dynamic languages, interpreted languages, OO from the ground up languages and scripting languages, it is more often the case that all functions are virtual, as function dispatch happens at runtime anyway. Examples here are the object-oriented languages smalltalk and Python. When object-oriented code is done in PERL or PHP, this model is also used.
In Java, for instance, all member functions are assumed to be virtual unless they are explicitly declared to be final.
As Ariels points out, with languages where all methods are virtual, the term is not much used except in explaining the language to novices. In everyday use of these languages, virtual functions are just the way things are.
The use of the virtual function is to enable polymorphism.
I would define a virtual function like this:
If a method on an object is called, then even if the caller has a variable typed as a base class type and no knowledge of which subclass they are dealing with, when the method is called the correct subclassed method (the override) is invoked.
Confusing? Let's do an example.
I have a class called Vehicle. It has a method called Drive. Of course, you cannot drive a generic vehicle, and all that the method body does is report an error that the method must be overridden in a subclass. It could also be a pure virtual method, also called an abstract method, meaning that it has no implementation and must be overridden by a subclass.
Naturally, I make two subclasses of Vehicle, say Bicycle and Truck. Both of these implement the Drive method, albeit by doing very different things.
Now if I have a piece of code that has a Vehicle object (which must be actually either a Bicycle or a Truck, but I have it typed as a Vehicle). This is standard OO programming, as the base class defines an interface contract which the subclasses must honour.
I call the Drive method, what happens? If the Drive method is not virtual, I get the error message as the Drive method on the Vehicle class is called, as the calling code only knows that it has a Vehicle. That's not what is wanted.
But if Drive is a virtual method, then the correct method will be called, even though the caller may be unaware of the exact type that they are dealing with.
To go further, this code that works with a Vehicle object need not be changed if I later write a third subclass of Vehicle, say Segway and ask the code to act upon this vehicle.
Virtual methods are implemented, as most things are, by introducting a layer of indirection.
In the case of compiled languages the indirection takes the form of a virtual method table between the caller and the method called. Each object has a table of virtual methods, and the caller looks up the address to call in this table. This is sometimes called runtime dispatch or dynamic binding.
The overhead for using this table is typically only a few machine instructions, and is thus in almost all cases a price well worth paying for the flexibility and extensibility.