Douglas C.

Schmidt

OO Programming with C++

Motivation
When designing a system it is often the case that developers:

Dynamic Binding C++

Douglas C. Schmidt
Professor [email protected] www.dre.vanderbilt.edu/ schmidt/ Department of EECS Vanderbilt University (615) 343-8197

1. Know what class interfaces they want, without precisely knowing the most suitable representation 2. Know what algorithms they want, without knowing how particular operations should be implemented In both cases, it is often desirable to defer certain decisions as long as possible Goal: reduce the effort required to change the implementation once enough information is available to make an informed decision

Copyright c 1997-2006

Vanderbilt University

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Motivation (contd)
Therefore, it is useful to have some form of abstract place-holder Information hiding & data abstraction provide compile-time & link-time place-holders  i.e., changes to representations require recompiling and/or relinking... Dynamic binding provides a dynamic place-holder  i.e., defer certain decisions until run-time without disrupting existing code structure  Note, dynamic binding is orthogonal to dynamic linking... Dynamic binding is less powerful than pointers-to-functions, but more comprehensible & less error-prone i.e., since the compiler performs type checking at compile-time
Copyright c 1997-2006 Vanderbilt University 2

Motivation (contd)
Dynamic binding allows applications to be written by invoking general methods via a base class pointer, e.g.,
class Base { public: virtual int vf (void); }; Base *bp = /* pointer to a subclass */; bp->vf ();

However, at run-time this invocation actually invokes more specialized methods implemented in a derived class, e.g.,
class Derived : public Base { public: virtual int vf (void); }; Derived d; bp = &d; bp->vf (); // invokes Derived::vf()

In C++, this requires that both the general and specialized methods are virtual methods
Copyright c 1997-2006 Vanderbilt University 3

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Motivation (contd)
Dynamic binding facilitates more exible and extensible software architectures, e.g., Not all design decisions need to be known during the initial stages of system development  i.e., they may be postponed until run-time Complete source code is not required to extend the system  i.e., only headers & object code This aids both exibility & extensibility Flexibility = easily recombine existing components into new congurations Extensibility = easily add new components

Dynamic vs. Static Binding

Inheritance review
A pointer to a derived class can always be used as a pointer to a base class that was inherited publicly  Caveats:  The inverse is not necessarily valid or safe  Private base classes have different semantics... e.g.,
template <typename T> class Checked_Vector : public Vector<T> { ... }; Checked_Vector<int> cv (20); Vector<int> *vp = &cv; int elem = (*vp)[0]; // calls operator[] (int)

A question arises here as to which version of operator[] is called?

Copyright c 1997-2006

Vanderbilt University

Copyright c 1997-2006

Vanderbilt University

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Dynamic vs. Static Binding (contd)

The answer depends on the type of binding used... 1. Static Binding: the compiler uses the type of the pointer to perform the binding at compile time. Therefore, Vector::operator[](vp, 0) will be called 2. Dynamic Binding: the decision is made at run-time based upon the type of the actual object. Checked Vector::operator[] will be called in this case as (*vp->vptr[1])(vp, 0) Quick quiz: how must class Vector be changed to switch from static to dynamic binding?

Dynamic vs. Static Binding (contd)

When to chose use different bindings Static Binding  Use when you are sure that any subsequent derived classes will not want to override this operation dynamically (just redene/hide)  Use mostly for reuse or to form concrete data types Dynamic Binding  Use when the derived classes may be able to provide a different (e.g., more functional, more efcient) implementation that should be selected at run-time  Used to build dynamic type hierarchies & to form abstract data types

Copyright c 1997-2006

Vanderbilt University

Copyright c 1997-2006

Vanderbilt University

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Dynamic vs. Static Binding (contd)

Efciency vs. exibility are the primary tradeoffs between static & dynamic binding
Static binding is generally more efcient since 1. It has less time & space overhead 2. It also enables method inlining Dynamic binding is more exible since it enables developers to extend the behavior of a system transparently However, dynamically bound objects are difcult to store in shared memory

Dynamic Binding in C++

In C++, dynamic binding is signaled by explicitly adding the keyword virtual in a method declaration, e.g.,
struct Base { virtual int vf1 (void) { cout << "hello\n"; } int f1 (void); };

Note, virtual methods must be class methods, i.e., they cannot be:  Ordinary stand-alone functions  class data  Static methods Other languages (e.g., Eiffel) make dynamic binding the default... This is more exible, but may be less efcient

Copyright c 1997-2006

Vanderbilt University

Copyright c 1997-2006

Vanderbilt University

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Virtual methods have a xed interface, but derived implementations can change, e.g.,
struct Derived_1 : public Base { virtual int vf1 (void) { cout << "world\n"; } };

C++ Virtual Methods

C++ Virtual Methods (contd)

Virtual method dispatching uses objects dynamic type to select the appropriate method that is invoked at run-time The selected method will depend on the class of the object being pointed at & not on the pointer type

Supplying virtual keyword is optional when overriding vf1() in derived classes, e.g.,
struct Derived_2 : public Derived_1 { int vf1 (void) { cout << "hello world\n"; } // Still virtual int f1 (void); // not virtual };

e.g.,
void foo (Base *bp) { bp->vf1 (); /* virtual */ } Base b; Base *bp = &b; bp->vf1 (); // prints "hello" Derived_1 d; bp = &d; bp->vf1 (); // prints "world" foo (&b); // prints "hello" foo (&d); // prints "world"

You can declare a virtual method in any derived class, e.g.,

struct Derived_3 : public Derived_2 { virtual int vf2 (int); // different from vf1! virtual int vf1 (int); // Be careful!!!! };
Copyright c 1997-2006 Vanderbilt University 10

Copyright c 1997-2006

Vanderbilt University

11

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

C++ Virtual Methods (contd)

virtual methods are dynamically bound and dispatched at run-time, using an index into an array of pointers to class methods Note, this requires only constant overhead, regardless of the inheritance hierarchy depth... The virtual mechanism is set up by the constructor(s), which may stack several levels deep...

Shape Example
The canonical dynamic binding example: Describing a hierarchy of shapes in a graphical user interface library e.g., Triangle, Square, Circle, Rectangle, Ellipse, etc. A conventional C solution would 1. Use a union or variant record to represent a Shape type 2. Have a type tag in every Shape object 3. Place special case checks in functions that operate on Shapes e.g., functions that implement operations like rotation & drawing

e.g.,
void foo (Base *bp) { bp->vf1 (); // Actual call // (*bp->vptr[1])(bp); }

Using virtual methods adds a small amount of time & space overhead to the class/object size and method invocation time
Copyright c 1997-2006 Vanderbilt University 12 Copyright c 1997-2006 Vanderbilt University 13

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

C Shape Example Solution

typedef struct { enum { CIRCLE, TRIANGLE, RECTANGLE, /* ... */ } type_; union { struct Circle { /* .... */ } c_; struct Triangle { /* .... */ } t_; struct Rectangle { /* .... */ } r_; // ... } u_; } Shape; void rotate_shape (Shape *sp, double degrees) { switch (sp->type_) { case CIRCLE: return; case TRIANGLE: // Dont forget to break! // ... } }
Copyright c 1997-2006 Vanderbilt University 14

Problems with C Shape Example Solution

It is difcult to extend code designed this way: e.g., changes are associated with functions and algorithms Which are often unstable elements in a software system design & implementation Therefore, modications will occur in portions of the code that switch on the type tag Using a switch statement causes problems, e.g., Setting & checking type tags Falling through to the next case, etc...

Copyright c 1997-2006

Vanderbilt University

15

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Problems with C Shape Example Solution (contd)

Data structures are passive i.e., functions do most of processing work on different kinds of Shapes by explicitly accessing the appropriate elds in the object This lack of information hiding affects maintainability Solution wastes space by making worst-case assumptions wrt structs & unions Must have source code to extend the system in a portable, maintainable manner

Object-Oriented Shape Example

An object-oriented solution uses inheritance & dynamic binding to derive specic shapes (e.g., Circle, Square, Rectangle, & Triangle) from a general Abstract Base class (ABC) called Shape This approach facilities a number of software quality factors: 1. 2. 3. 4. Reuse Transparent extensibility Delaying decisions until run-time Architectural simplicity

Copyright c 1997-2006

Vanderbilt University

16

Copyright c 1997-2006

Vanderbilt University

17

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Object-Oriented Shape Example (contd)

Note, the OOD challenge is to map arbitrarily complex system architectures into inheritance hierarchies

C++ Shape Class

// Abstract Base class & Derived classes for Shape. class Shape { public: Shape (double x, double y, Color &c) : center_ (Point (x, y)), color_ (c) {} Shape (Point &p, Color &c): center_ (p), color_ (c) {} virtual int rotate (double degrees) = 0; virtual int draw (Screen &) = 0; virtual Shape (void) = 0; void change_color (Color &c) { color_ = c; } Point where (void) const { return center_; } void move (Point &to) { center_ = to; } private: Point center_; Color color_; };

Circle

Triangle

Rectangle

Color

1
Point

1 1 1

Shape
A

Copyright c 1997-2006

Vanderbilt University

18

Copyright c 1997-2006

Vanderbilt University

19

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

C++ Shape Class (contd)

Note, certain methods only make sense on subclasses of class Shape e.g., Shape::rotate() & Shape::draw() The Shape class is therefore dened as an abstract base class Essentially denes only the class interface Derived (i.e., concrete) classes may provide multiple, different implementations

Abstract Base Classes (ABCs)

ABCs support the notion of a general concept (e.g., Shape) of which only more concrete object variants (e.g., Circle & Square) are actually used ABCs are only used as a base class for subsequent derivations Therefore, it is illegal to create objects of ABCs However, it is legal to declare pointers or references to such objects... ABCs force denitions in subsequent derived classes for undened methods In C++, an ABC is created by dening a class with at least one pure virtual method

Copyright c 1997-2006

Vanderbilt University

20

Copyright c 1997-2006

Vanderbilt University

21

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Pure Virtual Methods

Pure virtual methods must be methods They are dened in the base class of the inheritance hierarchy, & are often never intended to be invoked directly i.e., they are simply there to tie the inheritance hierarchy together by reserving a slot in the virtual table... Therefore, C++ allows users to specify pure virtual methods Using the pure virtual specier = 0 indicates methods that are not meant to be dened in that class Note, pure virtual methods are automatically inherited...

Pure Virtual Destructors

The only effect of declaring a pure virtual destructor is to cause the class being dened to be an ABC Destructors are not inherited, therefore: A pure virtual destructor in a base class will not force derived classes to be ABCs Nor will any derived class be forced to declare a destructor Moreover, you will have to provide a denition (i.e., write the code for a method) for the pure virtual destructor in the base class Otherwise you will get run-time errors!

Copyright c 1997-2006

Vanderbilt University

22

Copyright c 1997-2006

Vanderbilt University

23

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

In C++, special case code is associated with derived classes, e.g.,

class Circle : public Shape { public: Circle (Point &p, double rad); virtual void rotate (double degrees) {} // ... private: double radius_; }; class Rectangle : public Shape { public: Rectangle (Point &p, double l, double w); virtual void rotate (double degrees); // ... private: double length_, width_; };
Copyright c 1997-2006 Vanderbilt University 24

C++ Shape Example

C++ Shape Example (contd)

C++ solution (contd) Using the special relationship between base classes & derived subclasses, any Shape * can now be rotated without worrying about what kind of Shape it points to The syntax for doing this is:
void rotate_shape (Shape *sp, double degrees) { sp->rotate (degrees); // (*sp->vptr[1]) (sp, degrees); }

Note, we are still interface compatible with original C version!

Copyright c 1997-2006

Vanderbilt University

25

OO Progra

Douglas C. Schmidt
draw

OO Programming with C++

This code works regardless of what Shape subclass sp actually points to, e.g.,

C++ Shape Example (contd)

Vanderbilt University

C++ Shape Example (contd)

rotate

The C++ solution associates specializations with derived classes, rather than with function rotate shape() Its easier to add new types without breaking existing code since most changes occur in only one place, e.g.:
class Square : public Rectangle { // Inherits length & width from Rectangle public: Square (Point &p, double base); virtual void rotate (double degree) { if (degree % 90.0 != 0) // Reuse existing code Rectangle::rotate (degree); } /* .... */ };

vtable (Rectangle)

Rectangle

vptr

rotate_shape (&c, 100.0); rotate_shape (&r, 250.0);

rotate

draw

Circle c; Rectangle r;

Copyright c 1997-2006

Douglas C. Schmidt

vtable (Circle)

Circle

vptr

Copyright c 1997-2006

Vanderbilt University

27

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

C++ Shape Example (contd)

We can still rotate any Shape object by using the original function, i.e.,
void rotate_shape (Shape *sp, double degrees) { sp->rotate (degrees); } Square s; Circle c; Rectangle r; rotate_shape (&s, 100.0); rotate_shape (&r, 250.0); rotate_shape (&c, 17.0);

Comparing the Two Approaches

If support for Square was added in the C solution, then every place where the type tag was accessed would have to be modied i.e., modications are spread out all over the place Including both header les and functions Note, the C approach prevents extensibility if the provider of Square does not have access to the source code of function rotate shape()! i.e., only the header les & object code is required to allow extensibility in C++

Copyright c 1997-2006

Vanderbilt University

28

Copyright c 1997-2006

Vanderbilt University

29

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Comparing the Two Approaches (contd)

/* C solution */ void rotate_shape (Shape *sp, double degree) { switch (sp->type_) { case CIRCLE: return; case SQUARE: if (degree % 90 == 0) return; else /* FALLTHROUGH */; case RECTANGLE: // ... break; } }

Comparing the Two Approaches (contd)

Example function that rotates size shapes by angle degrees:
void rotate_all (Shape *vec[], int size, double angle) { for (int i = 0; i < size; i++) vec[i]->rotate (angle); }

vec[i]->rotate (angle) is a virtual method call It is resolved at run-time according to the actual type of object pointed to by vec[i] i.e.,
vec[i]->rotate (angle) becomes (*vec[i]->vptr[1]) (vec[i], angle);

Copyright c 1997-2006

Vanderbilt University

30

Copyright c 1997-2006

Vanderbilt University

31

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Comparing the Two Approaches (contd)

Sample usage of function rotate all() is

Comparing the Two Approaches (contd)

vtable (Circle) 0 rotate draw vtable (Square) 0 rotate draw

Shape *shapes[] = { new Circle (/* .... */), new Square (/* .... */) }; int size = sizeof shapes / sizeof *shapes; rotate_all (shapes, size, 98.6);

vptr Circle

vptr Square

Note, it is not generally possible to know the exact type of elements in variable shapes until run-time However, at compile-time we know they are all derived subtypes of base class Shape  This is why C++ is not fully polymorphic, but is strongly typed

shapes

Heres what the memory layout looks like

Copyright c 1997-2006

Vanderbilt University

32

Copyright c 1997-2006

Vanderbilt University

33

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Comparing the Two Approaches (contd)

Note that both the inheritance/dynamic binding & union/switch statement approaches provide mechanisms for handling the design & implementation of variants The appropriate choice of techniques often depends on whether the class interface is stable or not Adding a new subclass is easy via inheritance, but difcult using union/switch (since code is spread out everywhere) On the other hand, adding a new method to an inheritance hierarchy is difcult, but relatively easier using union/switch (since the code for the method is localized)

Calling Mechanisms
Given a pointer to a class object (e.g., Foo *ptr) how is the method call ptr->f (arg) resolved? There are three basic approaches: 1. Static Binding 2. Virtual Method Tables 3. Method Dispatch Tables C++ & Java use both static binding & virtual method tables, whereas Smalltalk & Objective C use method dispatch tables Note, type checking is orthogonal to binding time...

Copyright c 1997-2006

Vanderbilt University

34

Copyright c 1997-2006

Vanderbilt University

35

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Static Binding
Method fs address is determined at compile/link time Provides for strong type checking, completely checkable/resolvable at compile time Main advantage: the most efcient scheme e.g., it permits inline method expansion Main disadvantage: the least exible scheme

Virtual Method Tables

Method f() is converted into an index into a table of pointers to functions (i.e., the virtual method table) that permit run-time resolution of the calling address The *ptr object keeps track of its type via a hidden pointer (vptr) to its associated virtual method table (vtable) Virtual methods provide an exact specication of the type signature The user is guaranteed that only operations specied in class declarations will be accepted by the compiler

Copyright c 1997-2006

Vanderbilt University

36

Copyright c 1997-2006

Vanderbilt University

37

Douglas C. Schmidt

OO Programming with C++

Virtual Method Tables (contd) Virtual Method Tables (contd)

f2 2

OO Progra

Main advantages 1. More exible than static binding 2. There only a constant amount of overhead (compared with method dispatching) 3. e.g., in C++, pointers to functions are stored in a separate table, not in the object! Main disadvantages Less efcient, e.g., often not possible to inline the virtual method calls...

class Foo { public: virtual int f1 (void); virtual int f2 (void); int f3 (void); private: // data ... }; Foo obj_1, obj_2, obj_3;

vtable

obj 2

vptr

Copyright c 1997-2006

Vanderbilt University

38

Copyright c 1997-2006

Douglas C. Schmidt

obj 1

vptr

e.g.,

Vanderbilt University

f1

obj 3

vptr

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Method Dispatch Tables

Method f is looked up in a table that is created & managed dynamically at run-time i.e., add/delete/change methods dynamically Main advantage: the most exible scheme i.e., new methods can be added or deleted on-the-y & allows users to invoke any method for any object Main disadvantage: generally inefcient & not always type-secure May require searching multiple tables at run-time Some form of caching is often used Performing run-time type checking along with run-time method invocation further decreases run-time efciency Type errors may not manifest themselves until run-time
Copyright c 1997-2006 Vanderbilt University 40

Downcasting
Downcasting is dened as casting a pointer or reference of a base class type to a type of a pointer or reference to a derived class i.e., going the opposite direction from usual base-class/derived-class inheritance relationships... Downcasting is useful for 1. Cloning an object e.g., required for deep copies 2. Restoring an object from disk This is hard to do transparently... 3. Taking an object out of a heterogeneous collection of objects & restoring its original type Also hard to do, unless the only access is via the interface of the base class
Copyright c 1997-2006 Vanderbilt University 41

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Contravariance
Downcasting can lead to trouble due to contravariance, e.g.:
struct Base { int i_; virtual int foo (void) { return i_; } }; struct Derived : public Base { int j_; virtual int foo (void) { return j_; } }; void foo (void) { Base b; Derived d; Base *bp = &d; // "OK", a Derived is a Base Derived *dp = &b;// Error, a Base is not necessarily a Derived }

Contravariance (contd)
dp bp

b i

d i

Problem: what happens if dp->j_ is referenced or set?

Copyright c 1997-2006

Vanderbilt University

42

Copyright c 1997-2006

Vanderbilt University

43

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Contravariance (contd)
Since a Derived object always has a Base part certain operations are ok:
bp = &d; bp->i_ = 10; bp->foo (); // calls Derived::foo ();

Run-Time Type Identication (RTTI)

RTTI is a technique that allows applications to use the C++ run-time system to query the type of an object at run-time Only supports very simple queries regarding the interface supported by a type RTTI is only fully supported for dynamically-bound classes Alternative approaches would incur unacceptable run-time costs & storage layout compatibility problems

Since base objects dont have subclass data some operations arent ok e.g., accesses information beyond end of b:
dp = (Derived *) &b; dp->j_ = 20; // big trouble!

C++ permits contravariance if the programmer explicitly casts, e.g.,

dp = (Derived *) &b; // unchecked cast

Programmers must ensure correct operations, however...

Copyright c 1997-2006 Vanderbilt University 44 Copyright c 1997-2006 Vanderbilt University 45

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Run-Time Type Identication (contd)

RTTI could be used in our earlier example
if (Derived *dp = dynamic_cast<Derived *>(&b)) /* use dp */; else /* error! */

Run-Time Type Identication (contd)

dynamic cast used with references A reference dynamic cast that fails throws a bad cast exception

e.g.,
void clone (Base &ob1) { try { Derived &ob2 = dynamic_cast<Derived &>(ob1); /* ... */ } catch (bad_cast) { /* ... */ } }

For a dynamic cast to succeed, the actual type of b would have to either be a Derived object or some subclass of Derived if the types do not match the operation fails at run-time if failure occurs, there are several ways to dynamically indicate this to the application: To return a NULL pointer for failure To throw an exception e.g., in the case of reference casts...
Copyright c 1997-2006 Vanderbilt University 46

Copyright c 1997-2006

Vanderbilt University

47

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Run-Time Type Identication (contd)

Along with the dynamic cast extension, the C++ language now contains a typeid operator that allows queries of a limited amount of type information at run-time Includes both dynamically-bound and non-dynamically-bound types...

Run-Time Type Identication Examples

Base *bp = new Derived; Base &br = *bp; typeid typeid typeid typeid (bp) (bp) (bp) (bp) == == == == typeid typeid typeid typeid (Base *) // true (Derived *) // false (Base) // false (Derived) // false

e.g.,
typeid (type_name) yields const Type_info & typeid (expression) yields const Type_info &

typeid (*bp) == typeid (Derived) // true typeid (*bp) == typeid (Base) // false typeid (br) == typeid (Derived) // true typeid (br) == typeid (Base) // false typeid (&br) == typeid (Base *) // true typeid (&br) == typeid (Derived *) // false

Note that the expression form returns the run-time type of the expression if the class is dynamically bound...

Copyright c 1997-2006

Vanderbilt University

48

Copyright c 1997-2006

Vanderbilt University

49

Douglas C. Schmidt

OO Programming with C++

Douglas C. Schmidt

OO Programming with C++

Run-Time Type Identication Problems

RTTI encourages dreaded if/else statements of death e.g.,
void foo (Object *op) { if (Foobar *fbp = dynamic_cast<Foobar *> (op)) fbp->do_foobar_things (); else if (Foo *fp = dynamic_cast<Foo *> (op)) fp->do_foo_things (); else if (Bar *bp = dynamic_cast<Bar *> (op)) bp->do_bar_things (); else op->do_object_stuff (); }

Summary
Dynamic binding enables applications & developers to defer certain implementation decisions until run-time i.e., which implementation is used for a particular interface It also facilitates a decentralized architecture that promotes exibility & extensibility e.g., it is possible to modify functionality without modifying existing code There may be some additional time/space overhead from using dynamic binding... However, alternative solutions also incur overhead, e.g., the union/switch approach
50 Copyright c 1997-2006 Vanderbilt University 51

This style programming leads to an alternative, slower method of dispatching methods i.e., duplicating vtables in an unsafe manner a compiler cant check
Copyright c 1997-2006 Vanderbilt University