Thread: overhead of virtual functions

Which of the following options describe the expected overhead for a class that has 5 virtual functions?

A. Every object of the class holds the address of a link list object that holds the addresses of the virtual functions.
B. Every object of the class holds the address of the first virtual function, and each function in turn holds the address of the next virtual function.
C. Every object of the class holds the address of a structure holding the addresses of the 5 virtual functions.
D. Every object of the class holds the addresses of the 5 virtual functions.
E. Every object of the class holds the address of the class declaration in memory, through which the virtual function calls are resolved.

Ok, I would say:
* A I'm unsure - the object class has a vtable which stores a table of addresses to the virtual function, but is this a link list?
* B is incorrect has that is not how the vtable works
* C is incorrect, for the same reason as B
* D is correct because that describes the vtable correctly.
* E is incorrect, for the same reason as B

Can someone please confirm. Thx.

Try again

Code:

#include <iostream>

#define VIRT_FUNC(x) virtual void x() {}
struct Test
{
    VIRT_FUNC(a)
    VIRT_FUNC(b)
    VIRT_FUNC(c)
    VIRT_FUNC(d)
    VIRT_FUNC(e)
    int n;
};

int main()
{
    std::cout << sizeof(Test) << '\n';
    Test* t = new Test;
    std::cout << t << ' ' << &t->n << '\n';
}

(Although I don't think the standard actually specifies how the virtual mechanism needs to be implemented.)

It doesn't. If a compiler writer wants to implement this as #A or #D, he can. It would be really stupid, though.

I think this is a silly question that should be avoided, because each compiler is not required to implement it in the same way. Plus knowing this knowledge would do you no good, mostly, since trying to put it to use would likely be undefined.

In general, it is true that the compiler do not define how vtables are stored [or indeed that it is a "table" in any way - it just defines that the code should behave in a certain way when using the virtual keyword. How that is solved is entirely up to the compiler]

However, I have worked on code that assumes that the first thing in the memory inside the class is a vtable. The situation is that we have two objects that need to be distinguished through a void * because of the actual code receiving the pointer is a void * [because the pointer is passed across a C interface back to some C++ code], and we have no way to modify one of the classes for legacy reasons - the other class we do have full control over. Since the first class has virtual functions, and the second class DOESN'T, we put a "magic word" into the first element of the second class, which has properties that are UNLIKELY to ever be a valid vtable pointer, such as making sure that it is an odd value - and we use this MAGIC value to determine it is the new class, if that fails then validate that the "non-magic" value "is likely to be a vtable pointer" - if someone passes in some suitably incorrect pointer, we may mistake it for the first type of class - stupid users may be rewarded with a crash, but no legacy code SHOULD do that, and the old code didn't validate the pointer at all - so it would crash then too if a bad pointer was passed in [aside from the obvious check of a NULL pointer].

The comment to the function that uses the above trickery also explains that the the trickery IS implementation dependant, and may break with certain compilers. So far, it's been compiled with four different compiler versions, from three different vendors, and it's working correctly in all of those. But it is by no means absolutely certain to work IN ALL possible instances.

I'm not suggesting this as "GOOD" solution - and it certainly isn't super-portable.

--
Mats