Understanding Virtual Functions in C++

Imagine a piece of code that receives an object and needs to ask it to do something, such as draw itself or report its area. The caller would like to write one request and have the right behavior happen, whatever the object turns out to be. The difficulty is that the caller may not know how big the object is or how its data members are arranged in memory. If the caller had to know those details for every possible kind of object, the code would be fragile and tied to each concrete class.

The virtual function table, usually called the vtbl, is the mechanism that removes this need. Its job is to let the object be used correctly even when the caller has no knowledge of the object's size or internal data layout. This article follows that mechanism step by step, so you can see what the caller actually does and what the object provides.

Picture the moment a virtual call happens. The caller is holding an object, but it does not look inside that object to find the code it wants. Instead, it relies on two pieces of information. First, it knows where the pointer to the vtbl is located, relative to the object's container. Second, it knows the index that corresponds to the particular virtual function it wants to run. Using the pointer, the caller reaches the table. Using the index, it selects one entry in that table. The entry leads to the function that the object's class provides.

Notice what the caller never needs. It does not need the object's data members, their order, or the total size of the object. Those details belong to the class that defines the object. The caller only needs a fixed access pattern: follow the pointer, then pick the slot by index. The two facts are kept separate because that makes the mechanism easier to reason about. The next two parts examine each one in turn.

Now follow a single call through the mechanism. The caller holds an object and asks for a virtual function. It follows the vtbl pointer stored in that object to reach the table. It then uses the function's index to select the matching entry. The entry leads to the function the object's class supplies, and that function runs. At no point did the caller open up the object to read its data members or measure its size.

A natural worry is that following a pointer and then choosing an index must make every virtual call much slower than an ordinary call. The reference material addresses this directly. It says the virtual call mechanism can be made almost as efficient as the normal function call mechanism, within 25 percent. In other words, the extra work of going through the table is small enough that the difference is modest in practice.

This closeness is why virtual functions are a reasonable tool to use when the design calls for them. The extra cost is the pointer step plus the index step, and both are small compared with the benefit of letting one request produce the right behavior for many kinds of object.

Using the vtbl is not free in terms of memory. The source gives a precise accounting. Each object of a class with virtual functions carries one pointer, and each such class has one vtbl. The table belongs to the class and is not repeated for every object. The pointer, however, is stored in each object. This split explains why the cost scales in a useful way.