Thread: Pure Virtual Function - Virtual Method Table

The basic logic is simple.
In derived2, the vtable points towards derived2::display.
In derived1, the vtable points towards derived1::display.
In base, the vtable points towards base::display.
So the compiler just calls the correct function entry in the vtable and the correct function is called.
However, note that it may not be like this - the implementation may be done differently. Just know that it works and leave it at that.

As I say, it's implementation defined. All implementations are not required to do it in the same way, as long as it works, but one possible and very plausible explanation is that the vtable is static and is created by the constructor.
In dervied2's constructor, for example, the vtable is created and the function entry is set to point to derived2::display. What that entry looks like is also implementation defined, so again, it's difficult to speculate. They may just be numbered. The compiler can number each function starting from 0 and add n * sizeof(ptr) offset to the vtable to find the function to call.

As medievalelks says, implementation is the implementation's business.

That said, there are several things to notice here:

First, the =0 syntax for marking a function pure was probably derived from the idea of simply putting the null pointer in the vtable at that point.

Second, modern compilers put a small stub function there that emits a "Pure function called" error message and then aborts the application. To see this, you can run this (erroneous) program:

Code:

class Base
{
  void init() { do_virtual(); }
public:
  Base() { init(); }
  virtual void do_virtual() = 0;
  virtual ~Base() {}
};

class Derived
{
public:
  virtual void do_virtual() {}
};

int main()
{
  Derived d;
}

Compile without optimizations, or the compiler might optimize the entire call graph away.

Third, there's no particular reason why a vtable should be generated for an abstract class at all. Or at least I can't think of one.

There is absolutely no requirement in the standard that a class with a pure virtual function have ANY virtual function table.

The requirement comes down to the "function actually called in response to object->VirtualMember() is determined by the actual type of object".

A virtual function table is ONE WAY of meeting this requirement. Another way would be this sort of logic in (pseudo-code) -- which is actually a more literal interpretation of how the standard describes the requirement;

Code:

   if (object is of type_A)
          object->type_A::VirtualMember();
   else if (object is of type_B)
          object->type_B::VirtualMember();
   // etc

A virtual function table is the way this requirement is met by most real-world compilers, because the overhead is considered acceptable (memory overhead is a set of virtual tables per object, performance overhead once class is instantiated is fixed at runtime to retrieving function pointer from said tables, setting up argument list, and then dereferencing the function pointer).

One downside of virtual function tables is that they become quite complex in multiple-inheritance situations (typically classes with multiple bases require multiple vtables, and it is necessary to manage relationships between them). This is one reason (among several) that a lot of popular languages do not support multiple inheritance.

Originally Posted by CornedBee

First, the =0 syntax for marking a function pure was probably derived from the idea of simply putting the null pointer in the vtable at that point.

Not even remotely true.

The =0 syntax for pure virtual functions has nothing to do with the vtables. It is a signal to the compiler that the class should not be instantiated, and that derived classes also should not be instantiated unless they define a non-pure version of the same member function. There was some discussion by the standards committee about introducing a new keyword (eg "pure") to cover the same circumstance, but the "=0" syntax stuck.

There is no need to put a zero entry into a vtable for pure member functions, because a class that is not instantiated, by definition, does not need a vtable -- the vtable is populated when constructing the DERIVED class. Since code that attempts to instantiate an abstract class is required to trigger a COMPILATION error, an entry in a vtable (a RUN TIME entity) is not required.

Originally Posted by CornedBee

Second, modern compilers put a small stub function there that emits a "Pure function called" error message and then aborts the application.
<code elided>
Compile without optimizations, or the compiler might optimize the entire call graph away.

The code you describe here (when minor typos are fixed; you left out a "()") exhibits undefined behaviour (calling a pure virtual function in a constructor, or in a function called by a constructor), so any discussion of what "modern" compilers, or any other compilers, do with it is irrelevant.

Originally Posted by CornedBee

Third, there's no particular reason why a vtable should be generated for an abstract class at all. Or at least I can't think of one.

I won't debate with that one

Assuming that your compiler works with vtables ...... vtables are typically generated at run time when a class is instantiated. However, code that uses an abstract class (eg abstraction->VirtualMember()) forces the compiler to employ explicit assumptions about the layout and content of the vtable(s).

Not even remotely true.

The =0 syntax for pure virtual functions has nothing to do with the vtables. It is a signal to the compiler that the class should not be instantiated, and that derived classes also should not be instantiated unless they define a non-pure version of the same member function. There was some discussion by the standards committee about introducing a new keyword (eg "pure") to cover the same circumstance, but the "=0" syntax stuck.

There is no need to put a zero entry into a vtable for pure member functions, because a class that is not instantiated, by definition, does not need a vtable -- the vtable is populated when constructing the DERIVED class. Since code that attempts to instantiate an abstract class is required to trigger a COMPILATION error, an entry in a vtable (a RUN TIME entity) is not required.

What has the actual requirement to do with the origin of the syntax? What I said is true - Bjarne Stroustrup explicitly says so in "The Design and Evolution of C++".

And peculiarly enough, compilers often do generate vtables for abstract classes.

The code you describe here exhibits undefined behaviour, so any discussion of what "modern" compilers, or any other compilers, do with it is irrelevant.

I mentioned that the code is erroneous, and I didn't mean the missing () (fixed in the post now). However, experimental data on what the compilers actually can still be interesting in that it shows an implementation detail of those compilers.

vtables are typically generated at run time when a class is instantiated.

Huh? No, they're not. They're statically written into the executable. They're bound when the class is instantiated.