DOCSLIB.ORG

22. Subtyping, Inheritance and Polymorphism

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
22. Subtyping, Inheritance and Polymorphism Last Week: Expression Trees Goal: Represent arithmetic expressions, e.g. 2 + 3 ∗ 2 22. Subtyping, Inheritance and Arithmetic expressions form a tree structure Polymorphism + 2 ∗ 3 2 Expression Trees, Separation of Concerns and Modularisation, Type Expression trees comprise different nodes: literals (e.g. 2), binary Hierarchies, Virtual Functions, Dynamic Binding, Code Reuse, p Concepts of Object-Oriented Programming operators (e.g. +), unary operators (e.g. ), function applications (e.g. cos ), etc. 739 740 Disadvantages Disadvantages Implemented via a single node type: Observation: tnode is the “sum” of all required nodes – and every function must “dissect” this “sum”, e.g.: Value left operand operator right operand struct tnode { double eval(const tnode∗ n) { char op;// Operator (’=’ for literals) if (n−>op ==’=’) returnn −>val;//n isa constant + ? double val;// Literal’s value ?: unused double l = 0; tnode∗ left;// Left child(or nullptr) if (n−>left) l = eval(n−>left);//n is nota unary operator tnode∗ right;// ... = 2 ? ? ∗ ? double r = eval(n−>right); ... switch(n−>op) { }; case’+’: return l+r;//n is an addition node case’ ∗’: returnl ∗r;// ... ... Observation: tnode is the “sum” of all required nodes (constants, ) Complex, and therefore error-prone addition, . ) ) memory wastage, inelegant 741 742 Disadvantages New Concepts Today 1. Subtyping struct tnode { double eval(const tnode∗ n) { Type hierarchy: Exp represents char op; if (n−>op ==’=’) returnn −>val; Exp double val; double l = 0; general expressions, Literal etc. tnode∗ left; if (n−>left) l = eval(n−>left); are concrete expression tnode∗ right; double r = eval(n−>right); ... switch(n−>op) { Every Literal etc. also is an Exp Literal Addition Times }; case’+’: return l+r; (subtype relation) case’ ∗’: returnl ∗r; ... That’s why a Literal etc. can be used everywhere, where an Exp is expected: This code isn’t modular – we’ll change that today! Exp∗ e = new Literal(132); 743 744 New Concepts Today New Concepts Today 3. Inheritance 2. Polymorphism and Dynamic Dispatch Certain functionality is shared among Exp A variable of static type Exp can “host” expressions of different type hierarchy members dynamic types: E.g. computing the size (nesting Exp∗ e = new Literal(2);//e is the literal2 depth) of binary expressions Literal Addition Times e = new Addition(e, e);//e is the addition2+2 (Addition, Times): Exp Executed are the member functions of the dynamic type: 1 + size(left operand) + size(right operand) Exp∗ e = new Literal(2); ) Implement functionality once, and let std::cout << e−>eval();//2 subtypes inherit it Literal BinExp e = new Addition(e, e); std::cout << e−>eval();//4 Addition Times 745 746 Advantages Syntax and Terminology Exp Subtyping, inheritance and dynamic Exp binding enable modularisation struct Exp { BinExp Note: Today, we focus on the through spezialisation ... new concepts (subtyping, . ) Literal BinExp } Times Inheritance enables sharing common and ignore the orthogonal as- struct BinExp : public Exp { pect of encapsulation (class, code across modules Addition Times ... private vs. public member ) avoid code duplication } variables) Exp∗ e = new Literal(2); struct Times : public BinExp { std::cout << e−>eval(); ... } e = new Addition(e, e); std::cout << e−>eval(); 747 748 Syntax and Terminology Abstract Class Exp and Concrete Class Literal Exp struct Exp { . that makes Exp an abstract class virtual int size() const = 0; 1 struct Exp { BinExp BinExp is a subclass of Exp virtual double eval() const = 0; ... 2 Exp is the superclass of BinExp }; Enforces implementation by de- } Times Activates dynamic dispatch BinExp inherits from Exp rived classes . struct BinExp : public Exp { BinExp publicly inherits from Exp struct Literal : public Exp { Literal inherits from Exp ... ... (public), that’s why BinExp is a subtype double val; } of Exp struct Times : public BinExp { Analogously: Times and BinExp Literal(double v); ... Subtype relation is transitive: Times is int size() const; . but is otherwise just a regular class } also a subtype of Exp double eval() const; }; 1derived class, child class 2base class, parent class 749 750 Literal: Implementation Subtyping: A Literal is an Expression . Literal::Literal(double v): val(v) {} A pointer to a subtype can be used everywhere, where a pointer to a int Literal::size() const{ supertype is required: return 1; } Literal∗ lit = new Literal(5); Exp∗ e = lit; // OK: Literal is a subtype of Exp double Literal::eval() const{ return this−>val; } But not vice versa: Exp∗ e = ... Literal∗ lit = e; // ERROR: Exp is not a subtype of Literal 751 752 Polymorphie: . a Literal Behaves Like a Literal Further Expressions: Addition and Times struct Addition : public Exp { struct Times : public Exp { struct Exp { virtual member function: the dynamic (here: Literal) type Exp∗ left;// left operand Exp∗ left;// left operand ... Exp∗ right;// right operand Exp∗ right;// right operand virtual double eval(); determines the member function ... ... }; to be executed }; }; ) dynamic binding double Literal::eval() { int Addition::size() const{ int Times::size() const{ return this−>val; Without Virtual the static type return 1 + left−>size() return 1 + left−>size() } (hier: Exp) determines which + right−>size(); + right−>size(); function is executed } } We won’t go into further details Exp∗ e = new Literal(3); Separation of concerns std::cout << e−>eval();//3 Code duplication 753 754 Extracting Commonalities . : BinExp . Inheriting Commonalities: Addition Addition inherits member vari- struct BinExp : public Exp { struct Addition : public BinExp { ables (left, right) and func- Exp∗ left; Addition(Exp∗ l, Exp∗ r); tions (size) from BinExp Exp∗ right; double eval() const; }; BinExp(Exp∗ l, Exp∗ r); int size() const; }; Addition::Addition(Exp∗ l, Exp∗ r): BinExp(l, r) {} double Addition::eval() const{ Calling the super constructor BinExp::BinExp(Exp∗ l, Exp∗ r): left(l), right(r) {} (constructor of BinExp) initialises return the member variables left and this−>left−>eval() + right int BinExp::size() const{ this−>right−>eval(); return1+ this −>left−>size() + this−>right−>size(); } } Note: BinExp does not implement eval and is therefore also an abstract class, just like Exp 755 756 . Inheriting Commonalities: Times Further Expressions and Operations struct Times : public BinExp { Times(Exp∗ l, Exp∗ r); double eval() const; Further expressions, as classes derived from Exp, are possible, }; p e.g. −, =, , cos, log Times::Times(Exp∗ l, Exp∗ r): BinExp(l, r) {} A former bonus exercise (included in today’s lecture examples on Code Expert) illustrates possibilities: variables, trigonometric double Times::eval() const{ functions, parsing, pretty-printing, numeric simplifications, return this−>left−>eval() ∗ symbolic derivations, . this−>right−>eval(); } Observation: Additon::eval() and Times::eval() are very similar and could also be unified. However, this would require the concept of functional programming, which is outside the scope of this course. 757 758 Mission: Monolithic ! Modular X And there is so much more . struct Literal : public Exp { struct tnode { double val; char op; Not shown/discussed: ... double val; double eval() const{ tnode∗ left; return val; tnode∗ right; } Private inheritance ( ) ... classB: public A }; } struct Addition : public Exp { Subtyping and polymorphism without pointers double eval(const tnode∗ n) { ... if (n−>op ==’=’) returnn −>val; double eval() const{ double l = 0; return left−>eval() + right−>eval(); Non-virtuell member functions and static dispatch if (n−>left != 0) l = eval(n−>left); } double r = eval(n−>right); }; switch(n−>op) { (virtual double eval()) case’+’: return l + r; struct Times : public Exp { case’ ∗’: returnl − r; ... Overriding inherited member functions and invoking overridden case’ −’: returnl − r; double eval() const{ case’/’: return l / r; return left−>eval() ∗ right−>eval(); default: implementations } // unknown operator } assert (false); } Multiple inheritance struct Cos : public Exp { } ... double eval() const{ int size (const tnode∗ n) const { ... } ... return std::cos(argument−>eval()); } ... + } 759 760 Object-Oriented Programming Object-Oriented Programming In the last 3rd of the course, several concepts of object-oriented Subtyping (week 14): programming were introduced, that are briefly summarised on the upcoming slides. Type hierarchies, with super- and subtypes, can be created to model relationships between more abstract and more specialised entities Encapsulation (weeks 10-13): A subtype supports at least the functionality that its supertype supports – typically more, though, i.e. a subtype extends the interface (public section) of its Hide the implementation details of types (private section) from users supertype Definition of an interface (public area) for accessing values and functionality in That’s why supertypes can be used anywhere, where subtypes are required . a controlled way . and functions that can operate on more abstract type (supertypes) can also Enables ensuring invariants, and the modification of implementations without operate on more specialised types (subtypes) affecting user code The streams introduced in week 7 form such a type hierarchy: ostream is the abstract supertyp, ofstream etc. are specialised subtypes 761 762 Object-Oriented Programming Object-Oriented Programming Polymorphism and dynamic binding (week 14): A pointer of static typ T1 can, at runtime, point to objects of (dynamic) type T2, if Inheritance (week 14): T2 is a subtype of T1 Derived classes inherit
Load more

Recommended publications
  • Behavioral Subtyping, Specification Inheritance, and Modular Reasoning Gary T
    Computer Science Technical Reports Computer Science 9-3-2006 Behavioral Subtyping, Specification Inheritance, and Modular Reasoning Gary T. Leavens Iowa State University David A. Naumann Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Software Engineering Commons Recommended Citation Leavens, Gary T. and Naumann, David A., "Behavioral Subtyping, Specification Inheritance, and Modular Reasoning" (2006). Computer Science Technical Reports. 269. http://lib.dr.iastate.edu/cs_techreports/269 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Behavioral Subtyping, Specification Inheritance, and Modular Reasoning Abstract Behavioral subtyping is an established idea that enables modular reasoning about behavioral properties of object-oriented programs. It requires that syntactic subtypes are behavioral refinements. It validates reasoning about a dynamically-dispatched method call, say E.m(), using the specification associated with the static type of the receiver expression E. For languages with references and mutable objects the idea of behavioral subtyping has not been rigorously formalized as such, the standard informal notion has inadequacies, and exact definitions are not obvious. This paper formalizes behavioral subtyping and supertype abstraction for a Java-like sequential language with classes, interfaces, exceptions, mutable heap objects, references, and recursive types. Behavioral subtyping is proved sound and semantically complete for reasoning with supertype abstraction. Specification inheritance, as used in the specification language JML, is formalized and proved to entail behavioral subtyping.
    [Show full text]
  • Advances in Programming Languages Lecture 18: Concurrency and More in Rust
    Advances in Programming Languages Lecture 18: Concurrency and More in Rust Ian Stark School of Informatics The University of Edinburgh Friday 24 November 2016 Semester 1 Week 10 https://blog.inf.ed.ac.uk/apl16 Topic: Programming for Memory Safety The final block of lectures cover features used in the Rust programming language. Introduction: Zero-Cost Abstractions (and their cost) Control of Memory: Ownership Concurrency and more This section of the course is entirely new — Rust itself is not that old — and I apologise for any consequent lack of polish. Ian Stark Advances in Programming Languages / Lecture 18: Concurrency and More in Rust 2016-11-24 The Rust Programming Language The Rust language is intended as a tool for safe systems programming. Three key objectives contribute to this. Zero-cost abstractions Basic References Memory safety https://www.rust-lang.org https://blog.rust-lang.org Safe concurrency The “systems programming” motivation resonates with that for imperative C/C++. The “safe” part draws extensively on techniques developed for functional Haskell and OCaml. Sometimes these align more closely than you might expect, often by overlap between two aims: Precise control for the programmer; Precise information for the compiler. Ian Stark Advances in Programming Languages / Lecture 18: Concurrency and More in Rust 2016-11-24 Previous Homework Watch This Peter O’Hearn: Reasoning with Big Code https://is.gd/reasoning_big_code Talk at the Alan Turing Institute about how Facebook is using automatic verification at scale to check code and give feedback to programmers. Ian Stark Advances in Programming Languages / Lecture 18: Concurrency and More in Rust 2016-11-24 Guest Speaker ! Probabilistic Programming: What is it and how do we make it better? Maria Gorinova University of Edinburgh 3.10pm Tuesday 29 November 2016 Ian Stark Advances in Programming Languages / Lecture 18: Concurrency and More in Rust 2016-11-24 Optional: Review and Exam Preparation ! The final lecture will be an exam review, principally for single-semester visiting students.
    [Show full text]
  • Developing Rust on Bare-Metal
    RustyGecko - Developing Rust on Bare-Metal An experimental embedded software platform Håvard Wormdal Høiby Sondre Lefsaker Master of Science in Computer Science Submission date: June 2015 Supervisor: Magnus Lie Hetland, IDI Co-supervisor: Antonio Garcia Guirado, IDI Marius Grannæs, Silicon Labs Norwegian University of Science and Technology Department of Computer and Information Science Preface This report is submitted to the Norwegian University of Science and Technology in fulfillment of the requirements for master thesis. This work has been performed at the Department of Computer and Information Science, NTNU, with Prof. Magnus Lie Hetland as the supervisor, Antonio Garcia Guirado (ARM), and Marius Grannæs (Silicon Labs) as co-supervisors. The initial problem description was our own proposal and further developed in co-operation with our supervisors. Acknowledgements Thanks to Magnus Lie Hetland, Antonio Garcia Guirado, and Marius Grannæs for directions and guidance on technical issues and this report. Thanks to Silicon Labs for providing us with development platforms for us to develop and test our implementation on. Thanks to Antonio Garcia Guirado for the implementation of the CircleGame application for us to port to Rust and use in our benchmarks. Thanks to Itera w/Tommy Ryen for office space. A special thanks to Leslie Ho and Siri Aagedal for all the support and for proofreading the thesis. Sondre Lefsaker and H˚avard Wormdal Høiby 2015-06-14 i Project Description The Rust programming language is a new system language developed by Mozilla. With the language being statically compiled and built on the LLVM compiler infras- tructure, and because of features like low-level control and zero-cost abstractions, the language is a candidate for use in bare-metal systems.
    [Show full text]
  • Xtend User Guide
    Xtend User Guide September 10, 2013 Contents I. Getting Started 5 1. Introduction 6 2. Hello World 7 3. The Movies Example 9 3.1. The Data . .9 3.2. Parsing The Data . 10 3.3. Answering Some Questions . 11 3.3.1. Question 1 : What Is The Number Of Action Movies? . 11 3.3.2. Question 2 : What Is The Year The Best Movie From The 80's Was Released? . 12 3.3.3. Question 3 : What Is The The Sum Of All Votes Of The Top Two Movies?................................. 13 II. Reference Documentation 14 4. Java Interoperability 15 4.1. Type Inference . 15 4.2. Conversion Rules . 15 4.3. Interoperability with Java . 16 5. Classes and Members 17 5.1. Package Declaration . 17 5.2. Imports . 17 5.3. Class Declaration . 18 5.4. Constructors . 19 5.5. Fields . 19 5.6. Methods . 20 5.6.1. Abstract Methods . 20 5.6.2. Overriding Methods . 21 5.6.3. Declared Exceptions . 21 5.6.4. Inferred Return Types . 21 5.6.5. Generic Methods . 22 2 5.6.6. Dispatch Methods . 22 5.7. Annotations . 26 5.8. Extension Methods . 26 5.8.1. Extensions from the Library . 27 5.8.2. Local Extension Methods . 28 5.8.3. Extension Imports . 28 5.8.4. Extension Provider . 29 5.9. Interface Declaration . 29 5.10. Annotation Type Declaration . 30 5.11. Enum Type Declaration . 30 6. Expressions 31 6.1. Literals . 31 6.1.1. String Literals . 31 6.1.2. Character Literals . 32 6.1.3. Number Literals .
    [Show full text]
  • The Rust Programming Language
    The Rust Programming Language The Rust Team 2016-10-01 2 Contents 1 Introduction 11 Contributing ...................................... 11 2 Getting Started 13 Installing Rust ..................................... 13 Hello, world! ...................................... 16 Hello, Cargo! ...................................... 19 Closing Thoughts .................................... 23 3 Tutorial: Guessing Game 25 Set up .......................................... 25 Processing a Guess ................................... 26 Generating a secret number .............................. 30 Comparing guesses ................................... 33 Looping ......................................... 37 Complete! ........................................ 41 4 Syntax and Semantics 43 Variable Bindings ....................................... 43 Patterns ......................................... 43 Type annotations .................................... 44 Mutability ........................................ 44 Initializing bindings .................................. 45 Scope and shadowing .................................. 46 Functions ........................................... 48 Primitive Types ........................................ 53 Booleans ......................................... 53 4 CONTENTS char ........................................... 53 Numeric types ..................................... 54 Arrays .......................................... 55 Slices ........................................... 56 str ...........................................
    [Show full text]
  • COMP322 - Introduction to C++
    COMP322 - Introduction to C++ Lecture 09 - Inheritance continued Robert D. Vincent School of Computer Science 10 March 2010 Recall from last time I Inheritance describes the creation of derived classes from base classes. I Derived classes inherit all data and functions from their base classes, while certain functions such as constructors are handled specially. I Polymorphism is a product of the combination of virtual functions and C++ assignment compatibility rules. I We can create abstract types which contain “pure” functions that may have no implementation. We can’t actually create objects from these types, but we can create references or pointers to abstract types. Static dispatch If a member function is not virtual, the choice of function to call is made at compile time: class A{ int f(); }; class B: public A{ int f(); }; int main() { B b; A *pa = &b; pa->f(); // Calls A::f() because pa is of type 'A *' } This is called either “static dispatch” or “static binding”, and it is the default behavior in C++. Dynamic dispatch If a member function is virtual, the choice of function to call is made at run time: class A{ virtual int f(); }; class B: public A{ int f(); }; int main() { B b; A *pa = &b; pa->f(); // Calls B::f() because pa points to a 'B *' } Called either “dynamic dispatch” or “run-time binding”, this is both more useful and less efficient than static dispatch. Dynamic dispatch internals I Dynamic dispatch is implemented by adding a layer of indirection to a function call. I Any object with dynamic dispatch contains an automatically-generated pointer to a vtable.
    [Show full text]
  • Virtual Functions
    Virtual Functions OK, today’s topic in Object Oriented C++ is function dispatch. First, let’s review overloading. What is function overloading? Two methods or functions with the same signature. Why do you overload a function? For polymorphism. Now, mechanically, how do you overload something? Not only the method name, but the number and type of arguments and the return type must all match. Why? The name and arguments so that you know it’s an overload; the return type so that the compiler always knows the data types at run time… OK, so let’s create an example of overloading. Let’s say I have an Animal class with a “warm up” method. It might look like: Class Animal { Public: bool Warm-up() const {return false;} void Behave() { if (cold()) warm-up(); } }; Notice that is returns false, because there is no way for a generic Animal to warm up. But if we get more specific… Class Mammal : public Animal { Public: Bool Warm-up() const {shiver(); return true;} }; Notice that this is an example of function overloading, because the name, arguments and return type all match. Now, what happens if I write the following code? Mammal m; m.Behave(); In particular, which version of Behave() gets called? Notice that m is a mammal, but Behave() is a method of Animal, so inside Animal() the declared type of the object is Animal, not Mammal. If I did this example in Java, the answer is that the mammal would shiver and return true. But as written, in C++ the animal does nothing and Warm_up returns false.
    [Show full text]
  • Object-Oriented Programming
    CSE 143 Introduction •Classes have given us tremendous benefit •Encapsulation: make details of implementation and representation private Object-Oriented •Classes help break down and organize the task of Programming writing a program •Classes are designed to enable other benefits [Chapter 8] •Inheritance (subclassing) •Dynamic dispatch (polymorphism) •Two very powerful programming tools! •They help us write less code 2/20/99 336 2/20/99 337 Classes Using Other Classes Hierarchies of Organization •We've seen one way that a class can make use of •Often, we classify things in a hierarchy from another class general to specific •Use an instance of that class as a member variable Animal class PolyLine Mammal Fish Reptile { Canine Feline private: Tuna Shark PointArray pa; }; Wolf Dog Cat Iguana Croc •Objects have more of a "is-a-kind-of" relationship •We might call this a "has-a" relationship • • A Dog "is-a-kind-of" Canine, a Shark "is-a-kind-of" A PolyLine "has-a" PointArray Animal •This is often just called a “is-a” relation 2/20/99 338 2/20/99 339 Inheritance Example: A Point Class •Inheritance is a way to encode the "is-a-kind-of" •Let's say we had the relation in OO languages following class • class Point •Shark declares that it "is-a-kind-of" Fish by inheriting We can use inheritance to { create a class of colored public: from it Point( double x, double y ); • points based on this class A derived class inherits from a base class by putting double getX(); ": public BaseClassName" in the class declaration double getY(); GHULYHGÃFODVV EDVHÃFODVV
    [Show full text]
  • Object Oriented Programming Introduction
    Object Oriented Programming Introduction Object Oriented Programming Introduction to Computer Science II Definition Christopher M. Bourke Objected-Oriented Programming is a programming paradigm that uses [email protected] objects (data structures which have data fields and methods) which interact together within a computer program. Object Oriented Programming Object Oriented Programming Key Ideas Keep in mind When talking about OOP, keep in mind: I Modularity of design I Definitions are often blurred, authors/contexts may differ slightly I Encapsulation of data into Objects I Languages can have some, all, or none OOP features I Abstraction of an object’s behavior and representation I Programs can ignore or utilize some subset of features I Hierarchical organization of objects with subtypes inheriting behavior and state I Non-OOP languages can support some (or all!) OOP features without being “OOP” I Polymorphism ability of objects to have multiple forms in different contexts at different times I Debate still going as to “best” practices, how to do OOP, etc. I Understanding some concepts requires understanding other concepts Object Oriented Programming MotivationI Advantages Consider the evolution of computer languages I Facilitates modeling of real-world agents & problems I Machine Code Assembly Imperative Language I Supports modularity & decomposition → → I Clear demarcation of responsibilities and functionality I Each iteration still forces you to think in terms of a computer’s structure I Separates interface (the what) from implementation
    [Show full text]
  • Multimethods
    11-A1568 01/23/2001 12:39 PM Page 263 11 Multimethods This chapter defines, discusses, and implements multimethods in the context of Cϩϩ . The Cϩϩ virtual function mechanism allows dispatching a call depending on the dynamic type of one object. The multimethods feature allows dispatching a function call depending on the types of multiple objects. A universally good implementation requires language support, which is the route that languages such as CLOS, ML, Haskell, and Dylan have taken. Cϩϩ lacks such support, so its emulation is left to library writers. This chapter discusses some typical solutions and some generic implementations of each. The solutions feature various trade-offs in terms of speed, flexibility, and dependency management. To describe the technique of dispatching a function call depending on mul- tiple objects, this book uses the terms multimethod (borrowed from CLOS) and multiple dis- patch. A particularization of multiple dispatch for two objects is known as double dispatch. Implementing multimethods is a problem as fascinating as dreaded, one that has stolen lots of hours of good, healthy sleep from designers and programmers.1 The topics of this chapter include • Defining multimethods • Identifying situations in which the need for multiobject polymorphism appears • Discussing and implementing three double dispatchers that foster different trade-offs • Enhancing double-dispatch engines After reading this chapter, you will have a firm grasp of the typical situations for which multimethods are the way to go. In addition, you will be able to use and extend several ro- bust generic components implementing multimethods, provided by Loki. This chapter limits discussion to multimethods for two objects (double dispatch).
    [Show full text]
  • Multiple Dispatch and Roles in OO Languages: Ficklemr
    Multiple Dispatch and Roles in OO Languages: FickleMR Submitted By: Asim Anand Sinha [email protected] Supervised By: Sophia Drossopoulou [email protected] Department of Computing IMPERIAL COLLEGE LONDON MSc Project Report 2005 September 13, 2005 Abstract Object-Oriented Programming methodology has been widely accepted because it allows easy modelling of real world concepts. The aim of research in object-oriented languages has been to extend its features to bring it as close as possible to the real world. In this project, we aim to add the concepts of multiple dispatch and first-class relationships to a statically typed, class based langauges to make them more expressive. We use Fickle||as our base language and extend its features in FickleMR . Fickle||is a statically typed language with support for object reclassification, it allows objects to change their class dynamically. We study the impact of introducing multiple dispatch and roles in FickleMR . Novel idea of relationship reclassification and more flexible multiple dispatch algorithm are most interesting. We take a formal approach and give a static type system and operational semantics for language constructs. Acknowledgements I would like to take this opportunity to express my heartful gratitude to DR. SOPHIA DROSSOPOULOU for her guidance and motivation throughout this project. I would also like to thank ALEX BUCKLEY for his time, patience and brilliant guidance in the abscence of my supervisor. 1 Contents 1 Introduction 5 2 Background 8 2.1 Theory of Objects . 8 2.2 Single and Double Dispatch . 10 2.3 Multiple Dispatch . 12 2.3.1 Challenges in Implementation .
    [Show full text]
  • Interface-Based Programming in C++
    Term Paper Daniel Sarnow Interface-based Programming in C++ Fakultät Technik und Informatik Faculty of Engineering and Computer Science Studiendepartment Informatik Department of Computer Science Daniel Sarnow Title of the paper Interface-based Programming in C++ Keywords C++, Compiler Optimizations, Callgrind, Interface, polymorphism Abstract In many object oriented literature runtime polymorphism is often the only way mentioned to realize interface-based programming. In comparison to other languages, C++ oers more than just that. In C++ interface-based programming can also be achieved through link-time or compile-time polymorphism. This paper will show how interface-based programming can be done in C++ when using these three types of polymorphism. The dierent approaches are compared with each other at dierent compiler optimization levels. The paper will also show that compiler optimization mechanisms like inlining and devirtualization have been improved to minimize the overhead caused by dynamic dispatch even more. Contents 1 Introduction1 2 Approaches2 2.1 Runtime Polymorphism . .2 2.2 Link-Time Polymorphism . .4 2.3 Compile-Time Polymorphism . .5 2.3.1 Implicit Interface . .5 2.3.2 Curiously Recurring Template Pattern (CRTP) . .5 3 Comparing the Approaches7 3.1 Runtime Performance . .7 3.1.1 GCC Optimization Flags . 11 3.1.2 Measurement of execution time of the Approaches . 12 3.2 Memory Usage . 13 4 Conclusion 15 iii List of Tables 2.1 Necessity to use a certain interface implementation . .2 3.1 Execution time in milliseconds . 13 4.1 Necessity to use a certain interface implementation (II) . 15 List of Figures 2.1 Class diagram: Dynamic Approach .
    [Show full text]