Search

Enter your search terms

Submit search form

12.5 — The virtual table

By Alex on February 8th, 2008 | last modified by Alex on July 22nd, 2017

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:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

classBase

{

public:

virtualvoidfunction1(){};

virtualvoidfunction2(){};

};

classD1:publicBase

{

public:

virtualvoidfunction1(){};

};

classD2:publicBase

{

public:

virtualvoidfunction2(){};

};

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:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

classBase

{

public:

FunctionPointer*__vptr;

virtualvoidfunction1(){};

virtualvoidfunction2(){};

};

classD1:publicBase

{

public:

virtualvoidfunction1(){};

};

classD2:publicBase

{

public:

virtualvoidfunction2(){};

};

When a class object is created, *__vptr is set to point to the virtual table for that class. For example, when a 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:

1

2

3

4

intmain()

{

D1 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:

1

2

3

4

5

intmain()

{

D1 d1;

Base*dPtr=&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()?

1

2

3

4

5

6

intmain()

{

D1 d1;

Base*dPtr=&d1;

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 Base really pointed to a Base object instead of a D1 object. Would it still call D1::function1()?”. The answer is no.

1

2

3

4

5

6

intmain()

{

Baseb;

Base*bPtr=&b;

bPtr->function1();

}

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.

Good article.
I have a doubt regarding the vtable in derived class. Since object model of Derived class contains Base class part also, do we have a way out to get the vptr for the Base class from the Derived class? And if possible could you please cover the C-style to get the vptr using pointer casting from the object address?

I'm not sure what you mean by "get the vptr" -- the vptr isn't directly accessible. Are you asking how you'd use a Base classes virtual table with a Derived object? If so, I suppose you could always slice your object via a static_cast.

I meant to dig it down at object model, just for understanding how things work. I know that vptr is not directly accessible, but there must be some way out. And yes, I meant to access Base class methods from some pointer (not exactly from the C++ styled slicing but C styled pointer and casting). For eg. something like

Hi Alex,
Thanks for your wonderful explanation.It helped me a lot to get a clear picture of how the Vtable is organised. But could you please help me out the structure of Vtable if the methods in the base class are pure virtual?

Thanks Alex. One more doubt, I have seen below code in some website under the section ‘cross delegation/Delegating to a sister class’. So in the below case when i create an object of type class D, where will the function pointer for ‘function1()’ and ‘function2()’ in the ‘A’ part of the object ‘D’(vptrA in the below diagram) will point to ?Will it be pointing to the corresponding functions in the child class B and C? I am not able to get the clear understanding of the memory layout in this case. I am putting the diagram for the same with my understanding, I am not sure whether that is correct or not. Could you please help me a bit?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

classA{

public:

inta;

virtualvoidfunction1()=0;

virtualvoidfunction2()=0;

};

classB:publicvirtualA{

public:

intb;

virtualvoidfunction1()

{

function2();

}

};

classC:publicvirtualA{

public:

intc;

virtualvoidfunction2(){std::cout<<"Function2 in C"<<std::endl;}

};

classD:publicB,publicC{

public:

intd;

};

intmain()

{

D*p1=newD();

B*p2=p1;

A*p3=p1;

p1->function1();

p2->function1();

p3->function1();

}

Below diagram is just my understanding, I am not sure whether that is correct or not 🙁

As you've noticed, virtual tables for virtual classes are _very_ complicated, involving Thunks and pointers to typeinfo and other stuff. To be honest, I've never bothered to learn how these work at the virtual table level, because it didn't seem worth the time investment -- virtual classes are rare, and it's even rarer that you need to dig down to this level of detail. So you'll have to find this information elsewhere. My apologies.

See all those good comments, but nobody asked how this was true? At least was not explained.

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

I thought you just mentioned pClass only can access *__vptr is in the Base portion of the class

in D1. So D1 virtual table will have this new function. As per your explanation I should be able to access to function3() with pClass->__vptr. But that fails. I get compile error. What is explanation for that?
Thanks.

You shouldn't try to access the virtual table directly (nor should you ever need to). pClass->function3() should work fine. If you're getting an error, I'll need more code and the specific error you're getting to debug further.

Ah! I see what you're getting at. Given the above example, pClass->__vptr will point at D1's virtual table, which has Function3() in it (pointing to D1::Function3()). So in this particular case, this could resolve to a valid function call at runtime.

But as you've noted, the compiler won't even let you compile it (since Function3() isn't accessible through Base). Just because something is in the virtual table doesn't mean the compiler will let you use it.

Remember, the virtual table is a structure used at runtime to resolve function calls. But it doesn't control access -- the compiler handles whether you should or should not be able to call a function.