k. stirewalt cse 335: software design foundations: language mechanisms and primitive oo concepts...

CSE 335: Software Design K. Stirewalt

Foundations: Language Mechanisms and Primitive OO ConceptsLecture 2: Polymorphism

Topics:– Polymorphism and virtual functions in C++– Simple uses of polymorphism– Implementation of virtual and non-virtual functions– Common mistakes and need for virtual destructors

Pop quiz

void generateReport( Employee& empl ){ ... empl.print(cout); ...}

int main(void){ Employee doe(“John”, “Doe”, 235); Manager howell(“Charles”, “Howell”, 235, 3);

generateReport(howell);}

Question: Which method invoked to carry out this operation when empl is actually an instance of Manager?

Motivation

We should be able to develop clients that request an object to perform some operation and leave it to the object to choose the method

This capability, called polymorphism, is one of the defining characteristics of OO

In C++, we implement polymorphic operations by declaring member functions to be virtual

Example: declaring virtual functionclass Employee { private: string first_name, last_name; short department;

public: virtual void print( ostream& ) const;};

class Manager : public Employee {

private:

list<Employee*> group;

short level;

public:

void print( ostream& ) const;

Observe: function member declared virtual in base class.

Observe: no need to “redeclare” print as virtual.

Example: Virtual functions

int main(void)

Employee doe(“John”, “Doe”, 235);

Manager howell(“Charles”, “Howell”, 235, 3);

doe.print(cout); // invokes Employee::print()

howell.print(cout); // invokes Manager::print()

Employee* ePtr = &howell;

ePtr->print(cout); // invokes Manager::print()

Virtual-function definitions

void Employee::print( ostream& os ) const

os << “Name:” << first_name << “ “ << last_name

<< endl << “Dept: “ << department;

void Manager::print( ostream& os ) const

Employee::print(os);

os << “Level: “ << level;

Question: What happens here???

Exercise

We want to store different geometric objects in a list and compute their area. Develop a class hierarchy with classes Shape, Circle, and Rectangle. The following code should compile correctly:

list<Shape*> myShapes;

Circle* circ = new Circle(10);

Rectangle* rect = new Rectangle(20, 40);

myShapes.push_back(circ);

myShapes.push_back(rect);

for (list<Shape*>::iterator it = myShapes.begin();

it != myShapes.end(); it++)

cout << (*it)->area() << endl;

Heterogeneous containers

Inheritance + polymorphism can be used to implement containers that can hold different types of elements– Declare base class from which all element classes derive

• Base class declares a polymorphic operation– In C++, developer of base class declares a virtual member function

• Each element class may provide its own method for the operation

– Instantiate container with type “pointer to base class”– Clients, invoke operations on elements taken from

container without knowing actual type of the elements!

<<DETOUR>>

Henceforth, we will use polymorphism frequently and in combination with other language features to build reliable and reusable software structures

Because it is so central, it is important that you REALLY understand how it works

My theory: No better way than to look at how it is implemented!

Question

Thinking in terms of system-level resources, what is the mechanism by which virtual functions are actually implemented?

Answer: Each instance of a class that declares or inherits virtual member functions carries with it a pointer to a table (called a vtable) of pointers to member functions– When a virtual member function is invoked, a pointer to the function

to be dispatched is found by looking it up in the vtable.– Instances of different classes point to different vtables.– Owing to this indirection, a client may invoke the method

appropriate to the class used to originally instantiate the object without knowing that class!

Recall: Conceptual model of memory use by a running process

Process partitioned into 2 major chunks:– static part

• contains program code +• ... static data, vtables, etc

– dynamic part• contains run-time stack +

heap• all local variables and objects

created using new live here

Run-timestack

Programcode +

static data

Consider the following source codeclass C { protected: unsigned attr1; float attr2; …

public: void f1(…){…} … void vf1(…){…} void vf2(…){…}};

int main(void){ C myC1(8,32.0); C myC2(16, -64.5); myC2.vf2();}

Note: No virtual member functions yet; we’ll bring those in later.

Code compiled and linked...class C { protected: unsigned attr1; float attr2; …

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

main() {…}

a.outCompilation/linking

Program is executed...

class C { protected: unsigned attr1; float attr2; …

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

main() {…}

Program is executed...

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

main() {…}

Process begins executing in function main

Object myC1 constructed...

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

main() {…}

myC1attr1attr2

Object myC2 constructed

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

main() {…}

myC216-64.5

attr1attr2attr1attr2

-64.516

vf2() invoked on myC2

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

main() {…}

attr1attr2attr1attr2

C::vf2activation

Now let’s bring in the virtuals!

Consider these modifications to our source code

public: void f1(…){…} … virtual void vf1(…){…} virtual void vf2(…){…}};

Note: Only change to source is introduction of the 2 virtual keywords

main() {…}

Compiling and linking…

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

Class Cvtable

Note: Existence of virtual functions in class C caused the compiler to create a static object called the class C vtable.

main() {…}

Program is executed

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

Class Cvtable

main() {…}

Object myC1 created...

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

Class Cvtable

attr1attr2

main() {…}

Object myC1 created...

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

Class Cvtable

attr1attr2

Note: “extra” field in myC1

main() {…}

Creating myC2

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

myC216-64.5

Class Cvtable

attr1attr2

main() {…}

Creating myC2

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

myC216-64.5

Class Cvtable

attr1attr2

Note: “extra” field in myC2

main() {…}

Dynamic dispatch of vf2 [step 1]

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

myC216-64.5

Class Cvtable

attr1attr2

main() {…}

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

myC216-64.5

Class Cvtable

attr1attr2

main() {…}

C::f1(…){…}

…C::vf1(…){…}

C::vf2(…){…}…

myC216-64.5

Class Cvtable

attr1attr2

C::vf2activation

More interesting example

class D : public C { protected: unsigned attr3; …

public: void f1(…); … void vf1(…); void vf2(…); virtual void vf3(…);};

int main(void){ C myC1(8,32.0); D myD1(16, -64.5, 38); myD1.vf2()}

Question: How would the process memory map look in this example?

C::f1(…)

int main(void){ C myC1(8,32.0); D myD1(16, -64.5, 38); myD1.vf2();}

D::vf2(…)C::vf1(…)

C::vf2(…)

Class C vtable

16-64.5

D::vf3(…)

attr1attr2

38attr3

Class D vtable

D::vf1(…)D::f1(…)

main(…)

Exercise

void myPrint( Employee e )

e.print(cout);

int main(void)

Manager howell( … );

myPrint(howell);

Question: Which print method invoked when actual parameter is Manager?

Observe: Actual parameter is a value, not a reference.

Question

A compiler translates a program in one language into an equivalent program in another language, which is “closer to the machine”.

How would the compiler-generated code for function myPrint differ when Employee::print is virtual vs. non-virtual?

Code for myPrint (print NOT virtual)

pushl %ebpmovl %esp, %ebp

movl 8(%ebp), %eaxpushl $_coutpushl %eax

call _print__8EmployeeR7ostream

movl %ebp, %esppopl %ebp

Code for myPrint (print virtual)

pushl %ebpmovl %esp, %ebp

movl 8(%ebp), %edxpushl $_coutpushl %edx

movl 4(%edx), %ecx ; put vptr in ecxmovl 12(%ecx), %eax ; put address at offset

; 12 in vtable into eaxcall *%eax ; call function pointed to

; by eax

movl %ebp, %esppopl %ebp

Observations

Lots of things happen when we define an member function to be virtual– Better left to the compiler– No significant inefficiency (one extra indirection

per virtual function invocation)

Destructors in derived classes

class Target { public: Target() { numtargets++; } ~Target() { --numtargets; }

static int numberOfTargets() { return numtargets; }

private: static int numtargets;};

class Tank : public Target { public: Tank( const string& tId ) : tankId(tId) { numtanks++; }

~Tank() { numtanks--; }

static int numberOfTanks() { return numtanks; }

private: static int numtanks; const string tankID;};

Exercise

Target* target = new Tank(“T-19”);...delete target;

What happens here? (Think about what destructors are called)

Notice: base and derived classes

Virtual Destructor

class Target { public: Target() { numtargets++; } virtual ~Target () { --numtargets; }

static int numberOfTargets() { return numtargets; }

private: static int numtargets;};

Solution: Makedestructor virtual.

k. stirewalt cse 335: software design foundations: language mechanisms and primitive oo concepts...

virtual slide

virtual void print ostream

virtual destructors

stirewalt cse

public employee

employee doe john

virtual functions int

software design example

Documents

family resemblance vs. polymorphism · family resemblance...

genetic polymorphism

c++ polymorphism

polymorphism concept

chapter4 polymorphism

inheritance polymorphism

polymorphism (generics)

inheritance - polymorphism

polymorphism of pharmaceuticals with case...

c++ polymorphism systems programming. systems programming:...

understanding polymorphism

overridung polymorphism

supporting information - rsc.org · understanding...

10 polymorphism

polymorphism evaluatory

catechol-o-methyltransferase val158met polymorphism … ·...

dna polymorphism

r r r more frameworks acknowledgements: –k. stirewalt...

conformational polymorphism analysis polymorphism detection

genetic polymorphism