12.5 — The virtual table

To implement virtual functions, C++ uses a special form of late binding known as the virtual table. The virtual table is a lookup table of functions used to resolve function calls in a dynamic/late binding manner. The virtual table sometimes goes by other names, such as “vtable”, “virtual function table”, “virtual method table”, or “dispatch table”.

Because knowing how the virtual table works is not necessary to use virtual functions, this section can be considered optional reading.

The virtual table is actually quite simple, though it’s a little complex to describe in words. First, every class that uses virtual functions (or is derived from a class that uses virtual functions) is given its own virtual table. This table is simply a static array that the compiler sets up at compile time. A virtual table contains one entry for each virtual function that can be called by objects of the class. Each entry in this table is simply a function pointer that points to the most-derived function accessible by that class.

Second, the compiler also adds a hidden pointer to the base class, which we will call *__vptr. *__vptr is set (automatically) when a class instance is created so that it points to the virtual table for that class. Unlike the *this pointer, which is actually a function parameter used by the compiler to resolve self-references, *__vptr is a real pointer. Consequently, it makes each class object allocated bigger by the size of one pointer. It also means that *__vptr is inherited by derived classes, which is important.

By now, you’re probably confused as to how these things all fit together, so let’s take a look at a simple example:

Because there are 3 classes here, the compiler will set up 3 virtual tables: one for Base, one for D1, and one for D2.

The compiler also adds a hidden pointer to the most base class that uses virtual functions. Although the compiler does this automatically, we’ll put it in the next example just to show where it’s added:

When a class object is created, *__vptr is set to point to the virtual table for that class. For example, when an object of type Base is created, *__vptr is set to point to the virtual table for Base. When objects of type D1 or D2 are constructed, *__vptr is set to point to the virtual table for D1 or D2 respectively.

Now, let’s talk about how these virtual tables are filled out. Because there are only two virtual functions here, each virtual table will have two entries (one for function1() and one for function2()). Remember that when these virtual tables are filled out, each entry is filled out with the most-derived function an object of that class type can call.

The virtual table for Base objects is simple. An object of type Base can only access the members of Base. Base has no access to D1 or D2 functions. Consequently, the entry for function1 points to Base::function1() and the entry for function2 points to Base::function2().

The virtual table for D1 is slightly more complex. An object of type D1 can access members of both D1 and Base. However, D1 has overridden function1(), making D1::function1() more derived than Base::function1(). Consequently, the entry for function1 points to D1::function1(). D1 hasn’t overridden function2(), so the entry for function2 will point to Base::function2().

The virtual table for D2 is similar to D1, except the entry for function1 points to Base::function1(), and the entry for function2 points to D2::function2().

Here’s a picture of this graphically:

Although this diagram is kind of crazy looking, it’s really quite simple: the *__vptr in each class points to the virtual table for that class. The entries in the virtual table point to the most-derived version of the function objects of that class are allowed to call.

So consider what happens when we create an object of type D1:

Because d1 is a D1 object, d1 has its *__vptr set to the D1 virtual table.

Now, let’s set a base pointer to D1:

Note that because dPtr is a base pointer, it only points to the Base portion of d1. However, also note that *__vptr is in the Base portion of the class, so dPtr has access to this pointer. Finally, note that dPtr->__vptr points to the D1 virtual table! Consequently, even though dPtr is of type Base, it still has access to D1’s virtual table (through __vptr).

So what happens when we try to call dPtr->function1()?

First, the program recognizes that function1() is a virtual function. Second, the program uses dPtr->__vptr to get to D1’s virtual table. Third, it looks up which version of function1() to call in D1’s virtual table. This has been set to D1::function1(). Therefore, dPtr->function1() resolves to D1::function1()!

Now, you might be saying, “But what if dPtr really pointed to a Base object instead of a D1 object. Would it still call D1::function1()?”. The answer is no.

In this case, when b is created, __vptr points to Base’s virtual table, not D1’s virtual table. Consequently, bPtr->__vptr will also be pointing to Base’s virtual table. Base’s virtual table entry for function1() points to Base::function1(). Thus, bPtr->function1() resolves to Base::function1(), which is the most-derived version of function1() that a Base object should be able to call.

By using these tables, the compiler and program are able to ensure function calls resolve to the appropriate virtual function, even if you’re only using a pointer or reference to a base class!

Calling a virtual function is slower than calling a non-virtual function for a couple of reasons: First, we have to use the *__vptr to get to the appropriate virtual table. Second, we have to index the virtual table to find the correct function to call. Only then can we call the function. As a result, we have to do 3 operations to find the function to call, as opposed to 2 operations for a normal indirect function call, or one operation for a direct function call. However, with modern computers, this added time is usually fairly insignificant.

Also as a reminder, any class that uses virtual functions has a *__vptr, and thus each object of that class will be bigger by one pointer. Virtual functions are powerful, but they do have a performance cost.

12.6 -- Pure virtual functions, abstract base classes, and interface classes
12.4 -- Early binding and late binding

233 comments to 12.5 — The virtual table

  • Ryan

    Should we avoid virtual functions and limit the use where necessary, due to the performance cost?

    Am I right in saying that it would have to replicate and copy the virtual table and all the member function of the inherited classes for every instance of the derived class?

    For example a class Derived : public class Base, where Base has two virtual functions. Lets say its virtual void function1 ()and function2();

    Or am I correct or am I completely missing the point?

    • nascardriver

      Each instance only has a pointer to the vtable. The vtable is the same for all instances of the same type. The vtable never gets copied.

      Virtual functions have a minor run-time cost. They should only be avoided if you need very high performance (Really very high). There are better places to save performance, because avoiding virtual functions comes at the cost of reduced code quality.

  • Marat

    Hello, here are some small correction suggestions:
    "an object" instead of
    "a object"
    "(one for function1() and one for function2())" instead of
    "(one for function1(), and one for function2())"
    and just for consistancy "uses virtual functions has a *__vptr, and thus each" instead of
    "uses virtual functions has a __vptr, and thus each"
    I highly appreciate the effort you put into these incredible tutorials, thank you very much! :)

  • salah

    How each *__vptr is set to its appropriate virtual table?

    When deriving a variable that has a default value(in this case *__vptr has the address of VT of Base class) that variable will have the same value in both Derived and Base class. As a result, when accessing *__vptr of Derived, we will access the VT of Base! .So who changes the value of Derived::*__vptr making it points to VT of Derived class?

  • Miroslav Avramov

    What is difference between virtual and normal tables?

  • hugo

    Hey Alex & Nascardriver:
    In the last lesson, we knew we can do something like this:

    If in the vtable of each class it only stores pointers pointing to the most-derived version functions, how did the processor know to invoke the correct version of functions if we choose to ignore virtualization in the code?

  • Srinivas

    Hi Alex,

    Can you please make an example on how this virtual table and vptr works for multiple inheritance

    • Alex

      I'll respectfully decline this request. Virtual tables for multiple inheritance situations are complicated, and knowing how they work is not required to use C++ effectively (the primary objective of this tutorial series).

  • Steve

    Chiming in late to the discussion,

    There is a bit of information missing from the virtual table as described.

    Normally a virtual table will have an array of function pointers.   However, in addition to the function pointers you ALSO need a set of offsets.  This offset is applied to the this pointer such that it is moved either forward or backwards in the object layout so that not only is the virtual function called, but it is called with the correct object as it's this.

    Additionally, you also need a set of offsets for instance variables...   while normally an instance variable cannot be marked as virtual, what can be marked as virtual is the class as a whole.   Because the position of a virtual class in an inheritance hierarchy may change the location of the instance variable is therefore not constant across all layouts.   Therefore you need a set of offsets from the current this pointer to where the actual instance exists in the layout.

    more information can be found in the Itanium ABI which has become the defacto guideline for c++ virtual table layouts:

  • Manlin

    This is awesome, thank you!

  • hellmet

    I'm wondering, why can't this __vptr be made static, instead of attaching a copy of it to every instantiated class object?

    • nascardriver

      How do we know that `pBase->fn()` should call `Derived::fn`?
      There's no way of knowing what type `pBase` is pointing to, so we need to store some type information (A VTable pointer) in each instance.

      • hellmet

        Hmm... I was thinking, the derived object has the pointer to its vtable, and not to Base's vtable. So, when the Derived is cast into a Base object, it should still ...Oh I see, it won't still point to the derived vtable, since Base::__vprt would resolve to the Base's pointer. Got it, thanks!

  • Anastasia

    Oh, all the `main()`s in this lesson are affected by non-'return'ness as well... There also probably are a bunch I missed in the previous lessons of this chapter and most likely this issue is present in the future ones (which I haven't read yet). Should I even mention it in the future or it's considered normal (an alternative syntax)?

    • Alex

      Mention it if you see it. As far as issues go it's almost a non-issue, but I try to be consistent wherever possible. Thanks!

      • Anastasia

        For the next lessons in this chapter it seems to be the case only for the lessons 12.6 and 12.7 and 2c quiz question (the last snippet) in the 12x, the rest seems to be good.

        > As far as issues go it's almost a non-issue
        The only measures of issueness I have at the moment are my compiler warnings and nascardriver :D Sorry if I was bothering you for nothing.

        Thank you :)

  • Alex2

    Thanks for the explanation, Alex! It is perfectly understandable!

  • stephane

    Hi !

    ps: how the hell do i put that in readable code ?? XD

    • Alex

      The function call pA->bar() actually resolves to Derived::__vtable->bar(pA), where bar is a function pointer to Derived::Bar.

      Base's __vtable::bar points to Base::bar since Base (non-derived) objects calling bar() should get the Base version of the function.

      • yankee

        Hi Alex,

        For the above example code, because function bar() is only initialized in the Derived class, Base class pointer should have no access to bar(). Right?

        I have a question. Is the vtable of each class also a hidden public member or a private member?
        You explained that vtable is created for each class, which implies that it is individual to each class and turns out to be a private member. So basically, the compiler collects all virtual functions, including the inherited, overloaded, and firstly initialized, for each class and store the pointers of these functions to the vtable. Is this correct?


        • Functions aren't initialization, they're declared and defined.
          You can't access `bar` through `Base`, `Base` doesn't know what `bar` is.

          The vtable is not a class member, only a pointer to the vtable is stored in each instance. That way the same vtable can be used across several instances of a class. The vtable pointer is neither public nor private, you can't access it at all (Without trickery).

    • Mohit

      • > Derived vtable contains 2 entries: int func(int) & double func(double). Right?

        Problem 1
        `bd` is a `Base *`, you can only call functions that are part of `Base`. There is not `func(double)` is base, line 45 calls `func(int)`. Enable compiler warnings (warning: implicit conversion from 'double' to 'int' changes value from 2.3 to 2).

        Problem 2
        Say you change line 35 to

        You might expect line 39 to print `3`, but it won't. It calls `func(double)`. Re-using a function name in a derived class, without overriding a parent function, hides all parent functions with the same name. This produces a compiler warning (warning: 'Derived::func' hides overloaded virtual function).
        If you want both functions to be visible at the same time, you need to be `using` the parent function.

        Doing so produces the output you expected.

        - Don't use `using namespace`
        - Initialize your variables with brace initializers.
        - Limit your lines to 80 characters in length.

  • Arto Mihalache

    Hi, I wanted to say that I really appreciate these types of sections dedicated to explaining the internal implementations. As someone who's never really worked in a compiled language, its just very cool to me how many optimizations can be done before run-time, so thank you again very much for this :)

  • Anthony

    Let's say we have the following:

    As can be seen, D3 introduces a new virtual function, @function3(), in the middle of the chain of inheritance. I am wondering what is happening with *--vptr when this happens. D3 is a 'kind of' a new base class now, but there can't be two *--vpr's now. What happens here?

    Sorry to bother you, but I'm very curious.

    • Alex

      Since d is a D4, d's virtual pointer points to the virtual table for class D4, which includes function3 (inherited from D3).

    • Manish Baing

      I have one query with same code mentioned above.
      suppose I need to access  function1 D2 using base class pointer and D4 object is it possible to access it ...? i.e can we get access vptr D2 using base pointer holding dervied class object ...?

      • nascardriver

        It's very easy to break code by doing this. Restructure your code such that the original `D2::function1` doesn't get overridden by child classes and mark it `final`.

  • Anthony

    Hi Alex,

    I understand that any given class only has one vtable (a static array). But why does every object of that class have to have its own *__vptr pointer? Surely a single pointer (with static duration) would do?

    Loving this course. Thanks :)

    -- Anthony

    • But how does the object know where to find the static pointer?

      There's no information about the child here. The compiler cannot know which function @function is at compile-time. The only ways to resolve @function is to either store a pointer to the vtable in the child object, or store the child's type (eg. id) in the child object and look up the corresponding vtable.

  • Mehul

    Hi Alex,

    Can you please let me know when are the vtable loaded with the function addresses at compile time or at run time. If it is at runtime then is it when the instance of a class created else vtables are loaded same as static variables before the main function starts ?

    Are the vtable member variables, I think they are not. So are this stored in global scope. ?

    Are the vtables static tables ?

    Again Thanks is a small word for such a detailed tutorial it always helps me making my concepts stronger


    • Alex

      The vtables are set up at compile time (and hence are static rather than dynamic). The vtable pointer is a member pointer, and it's pointed at the correct vtable at runtime (upon object initialization).

  • Anand

    Where vtable will be stored(which segment)? Suppose if I have multiple objects of the same derived class, what is the behaviour of Vtable? means, storage, number of instances in total.

  • sowmyashree

    Will the memory allocated to a vtable of a class, will appear when we do sizeof(class)??

  • Hunter

    Hi Alex (or anyone else willing to answer my question),

    I'm a little confused about how virtual functions work. How does a Base pointer pointing to Derived object know it is pointing at a Derived object in order to resolve the virtual function call? If I understand correctly, the vtable is supposed to help with this, but it's still a little fuzzy to me.



    • Alex

      The virtual table for each class points to the most-derived versions of functions available to objects of that class. The virtual table pointer in a class object points at the virtual table for the Derived class.

      Therefore, for a Base pointer pointing to a Derived class, baseptr->__vptr will be pointing to Derived's virtual table (because the object is actually a Derived object, and therefore __vptr will be set to point to Derived's virtual table, per the above), and thus any function call made through that table will route to the most derived version of the function that a Derived object can call.

      Does that help?

  • Digendra Chand

    class Base
        virtual void function1() {}
        virtual void function2() {}

    class D1: public Base
        virtual void function1() {};

    As we can see in derived class D1 we have not overrided function2(). So as we know the V_table of class D1 will have only function1() in it.

    int main ()
      D1 d;
      D1*p =&d;
      return 0;

    here p->function2(); will call Base::function2().
    Can some body explain to me if Base::function2() is not present in vtable of D1 than how it is getting called?

  • sam

    I think "But what if Base really pointed to a Base object..." should be "But what if dPtr really pointed to a Base object...".

    Having great fun with these lessons by the way and I'm glad to see you're updating the site too.

  • Vijay

    Thank you for sharing valuable information guys. It is very helpful.

    Someone please clarify, if there is an overridden virtual function in derived class then does the derived class VTABLE will contain the addresses of non-overridden functions of base class as well?
    Please consider the folowing case:

    class base
        int x;
        virtual void f0() {}
        virtual void f1() {}

    class derived1 : public base
        int y;
        void f0() override {}
        void f1() override {}

    Please clarify: will the derived class VTABLE will also contain the addresses of base class's virtual functions:
    f0 (derived class overridden f0)
    f1 (derived class overridden f1)


    the derived class's VTABLE will only contain the addresses of overridden derived class's functions:
    f0 (derived class overridden f0)
    f1 (derived class overridden f1)

    As per the explanation provided in the below discussion, it seems like the derived class's VTABLE will only contain the addresses of overridden derived class's functions i.e. f0 and f1 (overridden in derived class). However, a clarification from someone would be very helpful to avoid ant confusion.

    Thank you in advance.


  • Mehul Shah

    Hi Alex,

    I have few  questions  regarding vptr

    1) As far as my understanding is there, vptr is a  intance variable not a class variable, is it corrent ?
    2) Base and Derived will have only 1 vptr or base has its own vptr and derived has its own vptr
    3) in the above code when i run in visual studio 2015 i see the address of obj1.vptr and obj2.vptr is same. how is this possible as vptr is a intance variable not class variable


    • nascardriver

      Hi Mehul!

      1) Correct.
      2) The classes don't have vtable pointers, they have vtables. @Base has it's own vtable and @Derived has it's own vtable.
      3) Each instance has it's own vtable pointer, this can point to whichever vtable you like. In your example you have two vtables, one for @Base and one for @Derived. You also have two vtable pointers, one in @obj1 and one in @obj2. Since both objects are of the same type (Base) they'll both point to the vtable of @Base.

  • Dimon

    moreover, the order of functions placed in the VFTs of each derived class is exact as they declared in the base object. that's all magic. let me show you:

    0:000> dps poi(bas) L4 (dump VFT of bas)
    0022aba0  00221154 tests!ILT+335(?f0baseUAEXXZ) f0 at index 0
    0022aba4  0022138e tests!ILT+905(?f1baseUAEXXZ) f1 at index 1
    0022aba8  00221230 tests!ILT+555(?f2baseUAEXXZ) f2 at index 2
    0022abac  002213c5 tests!ILT+960(?f3baseUAEXXZ) f3 at index 3

    0:000> dps poi(der1) L4 (dump VFT of der1, funcs was shuffled, do you remember? )
    0022abb8  002212d5 tests!ILT+720(?f0derived1UAEXXZ) f0 at index 0 as in base order
    0022abbc  002210aa tests!ILT+165(?f1derived1UAEXXZ) f1 at index 1 as in base order
    0022abc0  00221208 tests!ILT+515(?f2derived1UAEXXZ) f2 at index 2 as in base order
    0022abc4  00221096 tests!ILT+145(?f3derived1UAEXXZ) f3 at index 3 as in base order

    0:000> dps poi(der2) L6 (dump VFT of der2)
    0022abd0  00221154 tests!ILT+335(?f0baseUAEXXZ)     f0 at index 0 and not implemented by derived2 (points to base::f0)
    0022abd4  002211bd tests!ILT+440(?f1derived2UAEXXZ) f1 at index 1 as in base order
    0022abd8  00221316 tests!ILT+785(?f2derived2UAEXXZ) f2 at index 2 as in base order
    0022abdc  002213c5 tests!ILT+960(?f3baseUAEXXZ)     f3 at index 3 and not implemented by derived2 (points to base::f3)
    0022abe0  002212bc tests!ILT+695(?f6derived2UAEXXZ) f6 at index 4 and new VF starting from derived2 class
    0022abe4  002211f4 tests!ILT+495(?f5derived2UAEXXZ) f5 at index 5 and new VF starting from derived2 class

    thus the indexes of functions will always be kept, and with each new virtual function table will grow.
    and if the some virtual function is unimplemented in derived class, its place in class VF table will be replaced with pointer to base class VF.

    another words, if we will do like this:

    we will actually call base::f0. same for f3,
    hope this helps.

  • neil

    can D1 or D2 vtable holds function1 and 2 without virtual keywords?
    because it is accessible right? when we create base pointer to child object.

  • Mireska

    I'm so glad that the compiler is very smart and is able to do all this stuff, truly mindblowing

Leave a Comment

Put all code inside code tags: [code]your code here[/code]