Virtual Method Tables

1
Virtual Method Tables

• Explain the problem of dynamic binding
• Explain how compilers implement virtual methods
• Draw a VMT for an inheritance hierarchy
• Discuss the overhead associated with OO features
• Note much of this lecture is about how the
  compiler works.
• When programming, you dont implement virtual
  method tables.
• The compiler uses VMTs to implement inheritance
  efficiently

2
The Problem 1 Class Hierarchy

• TShape
• Properties
• x, y
• Virtual Methods
• hide(),
• draw(),
• show()

• TCircle public TShape
• Properties
• radius
• Virtual Methods
• draw()
• TSquare public TShape
• Properties
• height
• Virtual Methods
• draw()
• rotate()

3
Notes

• TShape implements hide() show()
• TCircle TSquare implement draw()
• Overriding the TShape draw() method
• TCircle c(20,20,10)
• TShape s new TCircle(50,50,10)
• c.draw() // right draw() known at compile time
• if (random(1)gt0.5)
• delete s
• s new TSquare(50,50,10)
• s-gtdraw() // code picks right draw() at run time

4
Dynamic Static Binding

• Static Binding
• The compiler generates a call to a specific
  routine
• Dynamic Binding
• The compiler generates code that selects the
  appropriate routine at run-time
• Essential for virtual methods
• Must call the method for the current object
• If using a pointer variable, dont know the type
  of the current object until run-time.

5
The Code

• TShape aShape3
• aShape0 new TCircle()
• aShape1 new TCircle()
• aShape2 new TSquare()
• aShape0 -gt draw()
• for (i 0 i lt 3 i)
• aShapei -gt draw()
• What code will the compiler generate?

6
Desirable Features

• The code generated must be
• Efficient
• Simple
• Consistent
• The same code should be generated for the same
  statement
• Flexible
• The same code must work with new descendent
  classes
• New classes can be written at any time
• Should not need to recompile calls to virtual
  methods

7
Possible Solution 1

• Work out the appropriate method at compile time
  call it
• e.g.
• push aShape0 // only works if the compiler
  knows
• call TCircledraw() // the type of the object
• Wont work for the loop - disaster when i 2
• push aShapei
• call TCircledraw()

8
Solution 2

• Check the type of the shape at run-time
• for (i 0 i lt 3 i)
• aShapei -gt draw()
• Compile the above draw() call to
• push aShapei
• if aShapei is TCircle
• call TCircledraw()
• else if aShapei is TSquare
• call TSquaredraw()

9
Problems

• Inefficient
• Doesn't allow reuse of code with newly defined
  classes
• e.g. A function to flash a shape
• called in a separately compiled file with a new
  shape descendent
• void flash(TShape s)
• s-gtdraw()
• pause()
• s-gthide()
• flash(new TStar()) // represents
  constructor parameters
• The if approach to calling draw() cant be used
  since the compiler cant know what new shapes
  there will be.

In flash.cpp Compiled to flash.obj in 2005
In usestar.cpp, written in 2006 Linked with
flash.obj in 2006
10
Virtual Method Tables

• Each 'object' needs a list of its own methods

VMT

Instance Data
hide()

show()

AShape0

x
TShape VMT


y

radius
draw()

AShape1


TCircle VMT

x

y

radius

draw()

AShape2

rotate()

x

y
TSquare VMT


height

Objects
1 VMT per class
Methods



11
How a VMT is used

• Virtual Method Table
• A table of addresses of the methods of a class
• A table of method pointers
• aShapei -gt draw()
• Design of code generated
• Virtual Method Table address from offset 0 in
  instance data
• Method Pointer Virtual Method Table1
• // compiler knows draw() is in offset 1 in
  VMT
• Call Method
• Same code will work whatever the type of the
  object

12
VMT Overheads applications

• When implemented in assembler, the extra cost of
  a method call is a table look-up.
• The first part of a VMT of a class must have the
  same order as that of its ancestors
• e.g. for descendents of shape, position 1 points
  to the appropriate draw() if draw() is in
  position 1 for shape.
• i.e. The offset of any virtual method of a class
  is the same in all of the classes ancestors.
• A circle/square VMT can be treated as a shape VMT

13
VMT Classes

• There is one VMT per class - more efficient
• The type of an object can be identified at
  run-time by the address of the VMT the basis of
  RTTI
• Precisely this structure is used in COM
• Microsofts Common Object Model which allows
  objects written in different languages to
  interact.
• COM objects are accessed through interfaces
• An interface is represented using a VMT
• More on this in Semester 2.

14
Abstract / Pure Methods

• No point in defining a draw() method for shape
• It must be overridden by every shape descendent
• Can define a method as pure
• No implementation is provided
• C syntax is virtual draw() 0
• C / Java call such methods abstract
• Declare the methods with the abstract keyword
• What value is in the VMT for a pure method?

15
Implementing Multiple Inheritance

• class C public A, B
• virtual void cm1()
• int Cfield

like VMT of class A new methods
Instance Data

am1()

am3()
Like an A object

bm1()


Afield
like VMT of class B
Like a B object
bm4()

Bfield
cm1()
Cfield
New method
myInstance
1 VMT section per ancestor
Methods
Objects


16
Implementing Multiple Inheritance

• class C public A, B
• virtual void cm1()
• int Cfield

B bptr new C() bptr -gt bm1() A aptr new
C() aptr -gt am1()
aptr
Instance Data
like VMT of class A

am1()

am3()
Like an A object

bm1()


Afield
like VMT of class B
Like a B object
bm4()

Bfield
cm1()
Cfield
myInstance
1 VMT section per ancestor
Methods
Objects
Seen through bptr, it looks just like a B object


bptr
17
Efficiency C vs C

• see http//www.eventhelix.com/RealtimeMantra/Basic
  s/ComparingCPPAndCPerformance.htm
• Method Invocation (Calls)
• Non-static C methods have an extra hidden
  parameter compared to the C equivalent. (The this
  pointer)
• But the C routine would need to access shared
  data, somehow.
• Overall small overhead for C
• Static Routines Identical to C functions
• Object Construction
• Constructor overhead can be reduced by inline.
• A C program would still require data
  initialisation.
• Little difference
• Object Destruction
• Only define destructors when necessary make
  inline
• A C program would still have to tidy up
• Little difference

18
Inheritance Overhead 1

• Constructors Destructors
• More overhead to call ancestor constructors/destru
  ctors
• Also VMT must be set up in the constructor
• Virtual Function Invocation
• Slightly more expensive in general code
• Optimizing compilers may insert a normal function
  call
• A virtual method call may replace a C switch
  statement
• A C object will be represented by a C structure
  with a type field and a Union field
• The C object code will be at least as efficient.

19
Example
20
Inheritance Overhead 2

• Memory Overhead
• Inheritance itself has no memory overhead.
• Inheritance with virtual functions
• Objects with virtual functions have a pointer to
  a class vtable
• Global vtable (VMT) for each class with virtual
  methods
• Multiple Inheritance
• More significant overhead

21
Summary

• Dynamic Binding
• Link to method at run-time
• s-gtdraw()
• Uses pointer
• Cant decide which draw() until run-time
• Virtual Method Table
• Provides dynamic binding efficiently
• One extra memory access per call
• One VMT for each class with virtual methods
• Small amount of space per class