Motivation Dynamic bindin facilitates more exible and extensible software architectures, e.., { Not all desin decisions need to be known durin the ini

Transcription

1 The C++ Prorammin Lanuae Dynamic Bindin Outline Motivation Dynamic vs. Static Bindin Shape Example Callin Mechanisms Downcastin Run-Time Type Identication Summary Motivation When desinin a system it is often the case that developers: 1. Know what class interfaces they want, without precisely knowin the most suitable representation 2. Know what alorithms they want, without knowin how particular operations should be implemented In both cases, it is often desirable to defer certain decisions as lon as possible { Goal: reduce the eort required to chane the implementation once enouh information is available to make an informed decision 1 2 Motivation Therefore, it is useful to have some form of abstract \place-holder" { Information hidin and data abstraction provide compile-time and link-time place-holders i.e., chanes to representations require recompilin and/or relinkin: :: { Dynamic bindin provides a dynamic place-holder i.e., defer certain decisions until run-time without disruptin existin code structure Note, dynamic bindin is orthoonal to dynamic linkin: :: Dynamic bindin is less powerful than pointersto-functions, but more comprehensible and less error-prone { i.e., since the compiler performs type checkin at compile-time 3 Motivation Dynamic bindin allows applications to be written by invokin eneral methods via a base class pointer, e.., class Base f 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.., class Derived : public Base f public: virtual int vf (void); ; Derived d; bp = &d; bp->vf (); // invokes Derived::vf() In C++, this requires that both the eneral and specialized methods are virtual functions 4

2 Motivation Dynamic bindin facilitates more exible and extensible software architectures, e.., { Not all desin decisions need to be known durin the initial staes 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 and object code This aids both exibility and extensibility { Flexibility = \easily recombine existin components into new conurations" { Extensibility = \easily add new components" Dynamic vs. Static Bindin Inheritance review { A pointer to a derived class can always be used as a pointer to a base class that was inherited publicly Caveats: { e.., 1. The inverse is not necessarily valid or safe 2. Private base classes have dierent semantics: :: template <class T> class Checked Vector : public Vector<T> f :::; 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? 5 6 Dynamic vs. Static Bindin The answer depends on the type of bindin used: :: 1. Static Bindin: the compiler uses the type of the pointer to perform the bindin at compile time. Therefore, Vector::operator[] will be called Vector::operator[](vp, 0); 2. Dynamic Bindin: the decision is made at runtime based upon the type of the actual object. Checked Vector::operator[] will be called in this case (*vp->vptr[1])(vp, 0); Quick quiz: how must class Vector be chaned to switch from static to dynamic bindin? Dynamic vs. Static Bindin When to chose use dierent bindins { Static Bindin 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 Bindin Use when the derived classes may be able to provide a dierent (e.., more functional, more ecient) implementation that should be selected at run-time Used to build dynamic type hierarchies and to form \abstract data types" 7 8

3 Dynamic vs. Static Bindin Eciency vs. exibility are the primary tradeos between static and dynamic bindin Static bindin is enerally more ecient since 1. It has less time and space overhead 2. It also enables function inlinin Dynamic bindin is more exible since it enables developers to extend the behavior of a system transparently { However, dynamically bound objects are dicult to store in shared memory Dynamic Bindin in C++ In C++, dynamic bindin is sinaled by explicitly addin the keyword virtual in a method declaration, e.., struct Base f virtual int vf1 (void) f cout << "hello\n"; int f1 (void); ; Note, virtual functions must be class methods, i.e., they cannot be: { Ordinary \stand-alone" functions { Class data { Static methods Other lanuaes (e.., Eiel) make dynamic bindin the default: :: { This is more exible, but may be less ecient 9 10 Dynamic Bindin in C++ Virtual functions: { These are methods with a xed callin interface, where the implementation may chane in subsequent derived classes, e.., struct Derived 1 : public Base f virtual int vf1 (void) f cout << "world\n"; ; { Supplyin the virtual keyword is optional when overridin vf1 in derived classes, e.., struct Derived 2 : public Derived 1 f // Still a virtual: :: int vf1 (void) f cout << "hello world\n"; int f1 (void); // not virtual ; { Note, you can declare a virtual function in any derived class, e.., struct Derived 3 : public Derived 2 f virtual int vf2 (int); // dierent from vf1! virtual int vf1 (int); // Be careful!!!! 11 Dynamic Bindin in C++ Virtual functions : { The virtual function dispatch mechanism uses the \dynamic type" of an object (identied by a reference or pointer) to select the appropriate method that is invoked at run-time The selected method will depend on the class of the object bein pointed at and not on the pointer type { e.., void foo (Base *bp) f bp->vf1 (); // virtual function 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" 12

4 Dynamic Bindin in C++ Virtual functions : { Virtual methods are dynamically bound and dispatched at run-time, usin an index into an array of pointers to class methods Note, this requires only constant overhead, reardless of the inheritance hierarchy depth: :: The virtual mechanism is set up by the constructor(s), which may stack several levels { e.., deep: :: void foo (Base *bp) f bp->vf1 (); // Actual call // (*bp->vptr[1])(bp); { Usin virtual functions adds a small amount of time and space overhead to the class/object size and method invocation time Shape Example The canonical dynamic bindin example: { Describin a hierarchy of shapes in a raphical user interface library { e.., Trianle, Square, Circle, Rectanle, Ellipse, etc. A conventional C or Ada solution would 1. Use a union or variant record to represent a Shape type 2. Have a type ta in every Shape object 3. Place special case checks in functions that operate on Shapes { e.., functions that implement operations like rotation and drawin C or Ada solution { e.., typedef struct Shape Shape; struct Shape f enum f CIRCLE, SQUARE, TRIANGLE, RECTANGLE /* Extensions o here: ::. */ type ; union f struct Circle f /* :::. */ c ; struct Square f /* :::. */ s ; struct Trianle f /* :::. */ t ; struct Rectanle f /* :::. */ r ; u ; ; void rotate shape (Shape *sp, double derees) f switch (sp->type ) f case CIRCLE: return; case SQUARE: // Don't foret to break! // ::: 15 Problems with the conventional approach: { It is dicult to extend code desined this way: e.., chanes are associated with functions and alorithms Which are often \unstable" elements in a software system desin and implementation Therefore, modications will occur in portions of the code that switch on the type ta Usin a switch statement causes problems, e.., Settin and checkin type tas Fallin throuh to the next case, etc: :: Note, Eiel disallows switch statements to prevent these problems! 16

5 Problems with the conventional approach : { Data structures are \passive" i.e., functions do most of processin work on dierent kinds of Shapes by explicitly accessin the appropriate elds in the object This lack of information hidin aects maintainability { Solution wastes space by makin worst-case assumptions wrt structs and unions { Must have source code to extend the system in a portable, maintainable manner An object-oriented solution uses inheritance and dynamic bindin to derive specic shapes (e.., Circle, Square, Rectanle, and Trianle) from a eneral Abstract Base Class (ABC) called Shape This approach facilities a number of software quality factors: 1. Reuse 2. Transparent extensibility 3. Delayin decisions until run-time 4. Architectural simplicity /* Abstract Base Class and Derived Classes for Shape */ class Shape f public: Shape (double x, double y, Color &c) : center (Point (x, y)), color (c) f Shape (Point &p, Color &c) : center (p), color (c) f virtual int rotate (double derees) = 0; virtual int draw (Screen &) = 0; virtual ~Shape (void) = 0; void chane color (Color &c) f this->color = c; Point where (void) const f return this->center ; void move (Point &to) f this->center = to; Note, the \OOD challene" is to map arbitrarily complex system architectures into inheritance hierarchies private: Point center ; Color color ; ; 19 20

6 Abstract Base Classes (ABCs) Note, certain methods only make sense on subclasses of class Shape { e.., Shape::rotate and Shape::draw Therefore, class Shape is dened as an Abstract Base Class { Essentially denes only the class interface { Derived (i.e., concrete) classes may provide multiple, dierent implementations 1. ABCs support the notion of a eneral concept (e.., Shape) of which only more concrete object variants (e.., Circle and Square) are actually used 2. ABCs are only used as a base class for subsequent derivations { Therefore, it is illeal to create objects of ABCs However, it is leal 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 denin a class with at least one \pure virtual function" { Compare with deferred classes in Eiel: :: Pure virtual functions { Pure virtual functions must be methods { They are dened in the base class of the inheritance hierarchy, and are often never intended to be invoked directly i.e., they are simply there to tie the inheritance hierarchy toether by reservin a slot in the virtual table: :: { Therefore, C++ allows users to specify \pure virtual functions" Usin the pure virtual specier = 0 indicates methods that are not meant to be dened in that class Note, pure virtual functions are automatically inherited: :: Side note reardin pure virtual destructors { The only eect of declarin a pure virtual destructor is to cause the class bein 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 { Furthermore, 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 et run-time errors! 23 24

7 The C++ solution to the Shapes example uses inheritance and dynamic bindin { In C++, the special case code is associated with the derived class data structures { e.., class Circle : public Shape f public: Circle (Point &p, double rad); virtual void draw (Screen &); virtual void rotate (double derees) f // ::: private: double radius ; ; class Rectanle : public Shape f public: Rectanle (Point &p, double l, double w); virtual void rotate (double derees); virtual void draw (Screen &); // ::: private: double lenth, width ; ; 25 C++ solution { Usin the special relationship between base classes and derived subclasses, any Shape * can now be \rotated" without worryin about what kind of Shape it points to { The syntax for doin this is: void rotate shape (Shape *sp, double derees) f sp->rotate (derees); // (*sp->vptr[1]) (sp, derees); { Note, we are still \interface compatible" with oriinal C version! 26 Characteristics of the C++ dynamic bindin solution: vtable (Circle) vtable (Rectanle) { Associate all specializations with the derived class 0 Rotate Draw 0 Rotate Draw Rather than with function rotate shape vptr Circle vptr Rectanle { This makes it possible to add new types (derived from base class Shape) without breakin existin code i.e., most extensions/chanes occur in only one place This code will continue to work reardless of what derived class of Shape that sp actually points to, e.., Circle c; Rectanle r; rotate shape (&c, 100.0); rotate shape (&r, 250.0); 27 { e.., add a new class Square derived from class Rectanle: class Square : public Rectanle f // Inherits lenth and width from Rectanle public: Square (Point &p, double base); virtual void draw (Screen &); virtual void rotate (double deree) f if (deree % 90.0!= 0) // Reuse existin code Rectanle::rotate (deree); /* :::. */ ; 28

8 C++ solution with dynamic bindin { We can still rotate any Shape object by usin the oriinal function, i.e., void rotate shape (Shape *sp, double derees) f sp->rotate (derees); Square s; Circle c; Rectanle r; rotate shape (&s, 100.0); rotate shape (&r, 250.0); rotate shape (&c, 17.0); Comparison between 2 approaches { If support for Square was added in the C or Ada solution, then every place where the type ta was accessed would have to be modied i.e., modications are spread out all over the place Includin both header les and functions Note, the C or Ada 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 and object code is required to allow extensibility in C Comparison between 2 approaches /* C solution */ void rotate shape (Shape *sp, double deree) f switch (sp->type ) f case CIRCLE: return; case SQUARE: if (deree % 90 == 0) return; else /* FALLTHROUGH */; case RECTANGLE: // ::: break; Example function that rotates size shapes by anle derees: void rotate all (Shape *vec[], int size, double anle) f for (int i = 0; i < size; i++) vec[i]->rotate (anle); vec[i]->rotate (anle) is a virtual function call { It is resolved at run-time accordin to the actual type of object pointed to by vec[i] { i.e., vec[i]->rotate (anle) becomes (*vec[i]->vptr[1]) (vec[i], anle); 31 32

9 Sample usae of function rotate all is Shape *shapes[] = f new Circle (/* :::. */), new Square (/* :::. */) ; int size = sizeof shapes / sizeof *shapes; rotate all (shapes, size, 98.6); vtable (Circle) 0 Rotate Draw 0 Rotate Draw vptr Circle vtable (Square) vptr Square Note, it is not enerally 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 shapes 0 1 This is why C++ is not fully polymorphic, but is stronly typed Here's what the memory layout looks like Callin Mechanisms Note that both the inheritance/dynamic bindin and union/switch statement approaches provide mechanisms for handlin the desin and implementation of variants The appropriate choice of techniques often depends on whether the class interface is stable or not { Addin a new subclass is easy via inheritance, but dicult usin union/switch (since code is spread out everywhere) { On the other hand, addin a new function to an inheritance hierarchy is dicult, but relatively easier usin union/switch (since the code for the function is localized) Given a pointer to a class object (e.., class Foo *ptr) how is the method call ptr->f (ar) resolved? There are three basic approaches: 1. Static Bindin 2. Virtual Function Tables 3. Method Dispatch Tables C++ and Java use both static bindin and virtual function tables. Smalltalk and Objective C use method dispatch tables Note, type checkin is orthoonal to bindin time: :: 35 36

10 Callin Mechanisms Static Bindin { Method f's address is determined at compile/link time { Provides for stron type checkin, completely checkable/resolvable at compile time { Main advantae: the most ecient scheme e.., it permits inline function expansion { Main disadvantae: the least exible scheme Callin Mechanisms Virtual Function Tables { Method f is converted into an index into a table of pointers to functions (i.e., the virtual function table) that permit run-time resolution of the callin address The *ptr object keeps track of its type via a hidden pointer (vptr) to its associated virtual function table (vtable) { Virtual functions provide an exact specication of the type sinature The user is uaranteed that only operations specied in class declarations will be accepted by the compiler Callin Mechanisms Callin Mechanisms Virtual Function Tables { Main advantaes 1. More exible than static bindin vptr obj 1 f1 f2 vtable There only a constant amount of overhead (compared with method dispatchin) e.., in C++, pointers to functions are stored in a separate table, not in the object! { Main disadvantaes Less ecient e.., often not possible to inline the virtual function calls: :: 39 e.., vptr obj 2 class Foo f public: virtual int f1 (void); virtual int f2 (void); int f3 (void); private: // data ::: ; Foo obj 1, obj 2, obj 3; vptr obj 3 40

11 Callin Mechanisms Method Dispatch Tables { Method f is looked up in a table that is created and manaed dynamically at run-time i.e., add/delete/chane methods dynamically { Main advantae: the most exible scheme i.e., new methods can be added or deleted on-the-y and allows users to invoke any method for any object { Main disadvantae: enerally inecient and not always type-secure May require searchin multiple tables at runtime Some form of cachin is often used Performin run-time type checkin alon with run-time method invocation further decreases run-time eciency Type errors may not manifest themselves until run-time 41 Downcastin Downcastin is dened as: { Either manually or automatically castin a pointer or reference of a base class type to a type of a pointer or reference to a derived class. { i.e., oin the opposite direction from usual \base-class/derived-class" inheritance relationships: :: Downcastin is useful for 1. Clonin an object { e.., required for \deep copies" 2. Restorin an object from disk { This is hard to do transparently: :: 3. Takin an object out of a heteroeneous collection of objects and restorin its oriinal type { Also hard to do, unless the only access is via the interface of the base class 42 Downcastin Contravariance { Downcastin can lead to trouble due to contravariance Downcastin It is consequence of inheritance that works aainst prorammers in a symmetrically opposin fashion to the way inheritance works for them dp bp { Consider the followin derivation hierarchy: b i d i struct Base f int i ; virtual int foo (void) f return this->i ; ; struct Derived : public Base f int j ; virtual int foo (void) f return this->j ; ; void foo (void) f Base b; Derived d; Base *bp = &d; // OK, a Derived is a Base Derived *dp = &b;// Error, a Base is not // necessarily a Derived 43? j is refer- Problem: what happens if dp->j enced or set? 44

12 Downcastin Contravariance { Since a Derived object always contains a Base part certain operations are well dened: bp = &d; bp->i = 10; bp->foo (); // calls Derived::foo (); { However, since base objects do not contain the data portions of any of their derived classes, other operations are not dened e.., this assinment accesses information beyond the end of object b: dp = (Derived *) &b; dp->j = 20; // bi trouble! { Note, C++ permits contravariance if the prorammer explicitly provides a downcast, e.., dp = (Derived *) &b; // unchecked cast { It is the prorammer's responsibility to make sure that operations upon dp don't access nonexistent elds or methods 45 Downcastin Traditionally, downcastin was necessary due to the fact that C++ oriinally did not support overloadin on function \return" type { e.., in C++ the followin is currently not allowed in most compilers: struct Base f virtual Base *clone (void); ; struct Derived : public Base f virtual Derived *clone (void); // Error! ; { However, assumin we make the appropriate virtual Base *clone (void) chane in class Derived: :: Base *ob1 = new Derived; Derived *ob2 = new Derived; { The followin are syntax \errors" (thouh they are actually type-secure): Derived *ob3 = ob1->clone (); // error Derived *ob4 = ob2->clone (); // error { To perform the intended operation, we must use a cast to \trick" the type system, e.., Derived *ob5 = (Derived *) ob1->clone (); 46 Downcastin The riht way to handle this is to use the C++ Run-Time Type Identication (RTTI) feature However, since most C++ compilers do not support type-safe downcastin, some workarounds include: 1. Don't do it, since it is potentially non-type-safe 2. Use an explicit cast (e.., ob5) and cross your ners 3. Encode type ta and write massive switch statements { Which defeats the purpose of dynamic bindin Run-Time Type Identication 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 reardin the interface supported by a type RTTI is only fully supported for dynamicallybound classes { Alternative approaches would incur unacceptable run-time costs and storae layout compatibility problems 4. Manually encode the return type into the method name: Derived *ob6 = ob2->clonederived (); 47 48

13 Run-Time Type Identication RTTI could be used in our oriinal example involvin ob1 Base *ob1 = new Derived; if (Derived *ob2 = dynamic cast<derived *>(ob1->clone ())) /* use ob2 */; else /* error! */ For a dynamic cast to succeed, the \actual type" of ob1 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.., in the case of reference casts: :: Run-Time Type Identication dynamic cast used with references { A reference dynamic cast that fails throws a bad cast exception e.., void clone (Base &ob1) f try f Derived &ob2 = dynamic cast<derived &>(ob1); /* :::*/ catch (bad cast) f /* :::*/ Run-Time Type Identication Alon with the dynamic cast extension, the C++ lanuae now contains a typeid operator that allows queries of a limited amount of type information at run-time { Includes both dynamically-bound and non-dynamicallybound types: :: e.., typeid (type name)! const Type info & typeid (expression)! const Type info & Note that the expression form returns the run-time type of the expression if the class is dynamically bound: :: Run-Time Type Identication Here are some short examples Base *bp = new Derived; Base &br = *bp; typeid (bp) == typeid (Base *) // true typeid (bp) == typeid (Derived *) // false typeid (bp) == typeid (Base) // false typeid (bp) == typeid (Derived) // false 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 51 52

14 Run-Time Type Identication A common ripe is RTTI will encourae the dreaded \switch statement of death," e.., void foo (Object *op) f op->do somethin (); if (Foobar *fbp = dynamic cast<foobar *> (op)) fbp->do foobar thins (); else if (Foo *fp = dynamic cast<foo *> (op)) fp->do foo thins (); else if (Bar *bp = dynamic cast<bar *> (op)) bp->do bar thins (); else op->do object stu (); Implementin this style of type tain by hand (rather than by the compiler) leads to an alternative, slower method of dispatchin methods { i.e., duplicatin the work of vtables in an unsafe manner that a compiler cannot double check { However, even an automated approach can be hard to make ecient! Summary Dynamic bindin enables applications and 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 and extensibility { e.., it is possible to modify functionality without modifyin existin code There is some additional run-time overhead from usin dynamic bindin: :: { However, alternative solutions also incur overhead e.., the union/switch approach 53 54