Übersetzung objektorientierter Sprachen André Christ Münster, 5. Januar 2007

Gliederung Objektorientierte Konzepte Übersetzung Klassen und Methoden Vererbung Parametrisierung Zusammenfassung & Fazit

Objektorientierte Programmierung Dr. Alan Kay: „Objektorientierte Programmierung“ Austausch von Nachrichten zwischen Objekten Objekte Zustand: Instanzvariablen Verhalten: Methoden Identität: Bei Erzeugung (Instanziierung) festgelegt (new) Nachrichten Anfrage, eine Operation auf einem Objekt auszuführen Zur Laufzeit wird „passende“ Methode ausgewählt und ausgeführt Syntax z.B.: obj.m() oder obj->m() 1. Objektorientierte Konzepte

Klassen und Methoden Klasse Methoden Beschreibt Menge von Objekten gleicher Struktur (Methoden, Instanzvariablen) Klassendefinition: Instanzvariablen und Methoden Führt neuen Datentyp ein Methoden Mögliche Operationen eines Objekts Vergleichbar mit Funktionen (Prozeduren) aus imperativen Sprachen Aber: Können auf Instanzvariablen ihres Objekts zugreifen (this) public class IntStack { private int size; // Instanzvariable private int[] data; // Instanzvariable public int pop() { // Methode return this.data[this.size – 1]; this.size--; } 1. Objektorientierte Konzepte

Vererbung Vererbung Teiltypregel B erbt von A: Alle Instanzvariablen und Methoden einer Superklasse A in der Unterklasse B enthalten Spezialisierung Unterklasse kann Instanzvariablen und Methoden hinzufügen Implementierung geerbter Methoden änderbar (Signatur gleich  Invariante Spezialisierung) Einfachvererbung (1 Superklasse, V-Baum) Mehrfachvererbung (n Superklassen, V-Graph) Teiltypregel a,b Variablen der Klassen A, B Zuweisung a = b gültig, falls A und B identisch oder B Unterklasse (auch indirekt) von A Zugriff nur über in A definierte Schnittstelle (A-Sicht auf B) 1. Objektorientierte Konzepte

Polymorphie Polymorphie („Vielgestaltigkeit“) Klassifikation Variablen, Datenobjekte sowie Argument- und Rückgabewerte können mehr als einen Datentypen annehmen Prinzip nicht auf objektorientierte Sprachen beschränkt Polymorphie insbesondere auch bei funktionalen Sprachen Klassifikation Subklassen-Polymorphie Parametrische-Polymorphie Überladen Coercion Universelle-Polymorphie Ad hoc-Polymorphie (Strachey / Cardelli, Wegner) Nach: Strachey / Cardelli, Wegner 1. Objektorientierte Konzepte

Subklassen-Polymorphie public class Kreis extends Figur {…} Kreis k = new Kreis(); k.Flaeche(); // Kreis::Flaeche() Figur f = new Kreis(); // Superklassenkontext f.Flaeche(); // Kreis::Flaeche() Anwendungsfall: Plugins / Frameworks Methoden-Auswahlregel Ein Objekt einer Unterklasse B von A kann im Superklassenkontext von A verwendet werden Methode m wird in Unterklasse überschrieben Methode m muss auch dann ausgeführt werden, wenn das Objekt B in Variable vom Typ A vorliegt (A-Sicht auf B) Erst zur Laufzeit bestimmbar, welche Instanz die Verarbeitung einer Nachricht übernimmt 1. Objektorientierte Konzepte

Parametrische-Polymorphie Motivation: Gleiche Funktionalität für mehrere Datentypen notwendig (insb. Datenbehältern) Bisher (Unsicherer Cast / Typüberprüfung) Generische Klasse mit formalem Parameter T Instanziierung mit aktuellem Parameter String: Stack oldStack = new Stack(); oldStack.push(new Integer(2)); String top = (String) oldStack.pop(); // Unsafe Downcast if (oldStack.pop() instanceof String) // instanceof type check public class Stack<T> { public void push(T element) {…} public T pop() {…} } Stack<String> stringStack = new Stack<String>(); stringStack.push("Hello World"); String top = stringStack.pop(); 1. Objektorientierte Konzepte

Gliederung Objektorientierte Konzepte Übersetzung Klassen und Methoden Vererbung Parametrisierung Zusammenfassung & Fazit

Übersetzung Aufspaltung des Übersetzungprozesses Abstrakte Maschine: Zwischencode, an Quellsprache angepasst Reale Maschine: Maschinencode, durch Prozessorarchitektur bestimmt (Weit verbreitet: CISC und RISC) Abstrakte Maschine für objektorientierte Sprache Programmspeicher (Zwischencode) Befehlsinterpreter (Ausführung des Zwischencodes) Stack (Methodeninkarnationen in Frames) Heap (u.a. Instanzen von Klassen) Virtuelle Maschine für objektorientierte Sprache Ausführungsumgebung moderner obj. Sprachen C# / Java Ausprägung einer abstrakten Maschine Ausführung des Zwischencodes zur Laufzeit des Programms 2. Übersetzung

Abstrakte Maschine 4 5 3 6 2 1 Verweis (Zeiger) Befehlszähler: Zeigt auf abzuarbeitenden Befehl in Methodenrumpf Framepointer: Verweist auf den Frame (lokale Variablen einer Methode) einer Methodeninkarnation (passend zu Befehlszähler) In Anlehung an: Bauer, Höllerer 1998 2. Übersetzung

Klassendeskriptor Methodentabelle: Indizierte Datenstruktur mit Methodenselektoren (Namen) Methodenselektor verweist auf entsprechenden Methodenrumpf im Methodenarray Detaillierung Klassendeskriptor: Auszug aus Java-class Datei: ClassFile { // Referenz auf Superklasse u2 super_class; // Anzahl Instanzvariablen u2 fields_count; // Name u. Typ d. Instanzvar. field_info fields[field_count]; // Anzahl der Methoden u2 methods_count; // Methodentabelle method_info methods[methods_count]; […] } In Anlehung an: Bauer, Höllerer 1998 2. Übersetzung // Klassen und Methoden

Übersetzung von Methoden (1) Methodenrumpf im Wesentlichen wie Funktions- oder Prozedurrümpfe imperativer Sprachen Variablen, Schleifen, Verzweigungen ... Objektorientierte Sprachkonstrukte (in Methoden) Senden einer Nachricht: Object.message() (auch O->m()) Zugriff auf Instanzvariable: Object.variable (auch O->v) Selbstreferenz: this (auch self) this.message() / this.variable Zugriff auf Superklasse: super (auch parent) super.message() / super.variable 2. Übersetzung // Klassen und Methoden

Übersetzung von Methoden (2) Realisierung der Selbstreferenz this Methode m einer Klasse K <ret> m(<args>) Übersetzt als Funktion: <ret> Km(K this, <args>) Nachricht m an Objekt o vom Typ K: <ret> o.m(<args>) Umgewandelt in Funktionsaufruf: <ret> Km(o, <args>) Methodennamen -> Funktionsnamen Problem: Globaler Namensraum von Funktionen Funktionen müssen sich in ihrem Namen unterscheiden Codierungsschema: _ZN#<Klasse>#<Methode>E<Typ>* (GNU G++ 3.0) Abbildung auf Konzept von Funktionen / Prozeduren imp. Sprachen Stack::push(int element) _ZN5Stack4pushEi Stack::push(float element) _ZN5Stack4pushEf Stack::push(float comp, float imag) _ZN5Stack4pushEff 2. Übersetzung // Klassen und Methoden

Methodenaufrufe Statisches Binden (imp. Prozedur- und Funktionsaufruf) Funktionsaufruf wird zur Übersetzungszeit der Definition der Funktion zugeordnet Nach Typüberprüfung von Argument- und Rückgabewerten legt Übersetzer relative Speicheradresse fest Dynamische Bindungsregel „Überschreibt eine Klasse B eine Methode ihrer Superklasse A und wird eine Nachricht m an ein Objekt geschickt, dessen Klassenzugehörigkeit zur Übersetzungszeit nicht bekannt ist, so muss die Methodenimplementierung zur Laufzeit an das Objekt gebunden werden.“ Bauer, Höllerer 1998 2. Übersetzung // Vererbung

Dynamisches Binden mittels vtable Virtuelle Methodentabelle (vtable) In C++ auch virtuelle Funktionstabelle Sog. virtuelle Methoden in Unterklassen überschreibbar Einträge in der vtable verweisen auf Methodenimplementationen Sichten: Offsets in der vtable (siehe geschweifte Klammern) 2. Übersetzung // Vererbung

Realisierung vtable in C++ Instanziierung Quadrat q = new Quadrat(); Objekt erhält Zeiger auf vtable seiner Klasse Methodenaufruf q->Flaeche(); In der vtable wird Adresse der Funktionsimplementation nachgeschlagen Effiziente Implementation durch Funktionszeiger in C: Standardisierte Indezierung der vtable Umwandlung der Methodenaufrufe: q->Flaeche()  (*(q->vtable[0]))() 2. Übersetzung // Vererbung

Realisierung vtable in C++ Subklassen-Polymorphie Quadrat q = new Quadrat(); Rechteck f = (Rechteck) q; f->Flaeche(); Sicht über vtable des Objekts vom Typ Quadrat 2. Übersetzung // Vererbung

Mehrfachvererbung Diamant Problem (Auszug) Wiederholte Beerbung: Figur und Linie erhalten Methoden und Instanzvariablen die sie an Rechteck weitervererben Uneindeutigkeit wegen doppelter Methodennamen und Instanzvariablen (Skalieren()) Lösungsansatz: Echte Mehrfachvererbung vermeiden Mehrfachvererbung nur mit Superklassen ohne Implementierungsteil (Java, C#) z.B. Java Interfaces: public class Rechteck implements Figur, Linie { [...] } Parallelpfad Realisierung 2. Übersetzung // Vererbung

Übersetzung von Parametrisierung Ursprung in funktionaler Sprache ML Viel Gesprächsstoff bzgl. Umsetzung von Parametrisierung in objektorientierten Sprachen In C++, Java und C# nachträglich hinzugefügt Unterschiedliche Strategien C++ Templates Java Generics (ab J2SE 5.0) C# Generische Klassen (ab .NET 2.0) “Correction these early oversights in C++ was a long and painful process, creating years of havoc as compilers never quite supported the same language, books never quite gave accurate information, trainers never quite taught the right stuff, and programmers never quite knew what to think“ (Betrand Mayer 1998, Entwickler der Programmiersprache Eiffel) 2. Übersetzung // Parametrisierung

Parametrisierung in C++ (1) Generische Klassen: C++ Templates Übersetzer expandiert Templates anhand aktueller Parameter Für jeden aktuellen Parameter eigene Klasse Daher: Kopierende (auch heterogene) Übersetzung 2. Übersetzung // Parametrisierung

Parametrisierung in C++ (2) Umsetzung der Methodenaufrufe durch C++ Compiler Stack<int> intStackA; Stack<int> intStackB; intStackA.push(1); intStackB.push(2); Stack<float> floatStack; floatStack.push(1); floatStack.pop(); _ZN5StackIiE4pushEi _ZN5StackIfE4pushEf _ZN5StackIfE3popEv 2. Übersetzung // Parametrisierung

Parametrisierung in C++ (3) Strategie Dem Übersetzungsprozess vorgeschaltete Expansion Vgl. mit Makro-Expansion durch Präprozessor in C Bewertung Performanz Laufzeit: Parametrisierung bringt keinen Overhead mit sich – da Abbildung auf bekannte Sprachkonstrukte Keine Integration in den Sprachkern – generische Klassen sind nicht Bestandteil des Typsystems Programmgröße wächst stark an (Redundanter Code)    2. Übersetzung // Parametrisierung

Parametrisierung in Java (1) Java Generics Hervorgegangen aus Pizza-Projekt (später GJ-Projekt) Anforderung: Auf unveränderter JVM lauffähig Seit J2SE 5.0 offizieller Bestandteil Erasure Java-Compiler überprüft Typen (aktuelle Parameter) Formale Parameter werden durch ihren Bound ersetzt und Typkonvertierungen eingefügt Ergebnis: Raw Type, frei von generischen Instuktionen Auch: Homogene Übersetzung Bound (Obere Grenze): Implizit Object: class Stack<T> {...} Explizit Number: class Stack<T extends Number> {...} 2. Übersetzung // Parametrisierung

Parametrisierung in Java (2) Beispiel Erasure Stack<T> mit Bound Object: Generische Klasse: Raw Type (nach Erasure): public class Stack<T> { public void push(T element){…} public T pop() {…} } Stack<String> st = new Stack<String>(); st.push("Hello World"); String top = st.pop(); public class Stack { public void push(Object element){…} public Object pop() {…} } Stack st = new Stack(); st.push("Hello World"); String top = (String) st.pop(); 2. Übersetzung // Parametrisierung

Parametrisierung in Java (3) Probleme (u.a.) Bewertung Keine Anpassungen an JVM nötig (Prämisse an Pizza-Projekt) Overhead durch Typkonvertierungen Generische Typen existieren zur Laufzeit nicht mehr stack instanceof Stack<Integer> nicht möglich Primitive Typen (int, float) können keine aktuellen Parameter sein, da kein gemeinsamer Bound existiert Stack<String> strStack = new Stack<String>(); strStack.push("Test"); Object tmp = strStack; Stack<Integer> intStack = (Stack<Integer>) tmp; // Unchecked cast // without type [...] Integer intVal = intStack.pop(); // CastException // later in Code     2. Übersetzung // Parametrisierung

Parametrisierung in C# (1) Kompatibilität generischer Klasseninstanzen Datenstrukturen und Algorithmen der aktuellen Parameter identisch Referenztypen zueinander kompatibel (32-bit Pointer) Primitiven Datentypen untereinander und zu Referenzzypen inkompatibel Kopie der virtuellen Methodentabelle für jede generische Klasseninstanz Kompatible Klasseninstanzen verweisen auf gemeinsamen Code 2. Übersetzung // Parametrisierung

Parametrisierung in C# (2) Strategie Kombination der Vorteile der heterogenen Übersetzung (C++) und der homogenen Übersetzung (Java) Bauer, Höllerer: Echte generische Übersetzung Bewertung Völlständige Integration generischer Typen in den Sprachkern Typüberprüfungen auch zur Laufzeit möglich Wenig Overhead zur Laufzeit da Typkonvertierungen nicht nötig Zusätzliche Verwaltung von vtables (Aber: Effiziente Implementation mit vtable Dictionaries möglich)     2. Übersetzung // Parametrisierung

Gliederung Objektorientierte Konzepte Übersetzung Klassen und Methoden Vererbung Parametrisierung Zusammenfassung & Fazit

Zusammenfassung & Fazit Grundlagen objektorientierter Sprachen Klassen und Objekte Methoden und Nachrichten Polymorphie Übersetzung Abstrakte Maschine Klassen und Methoden  Gemeinsamkeiten mit imp. Prozeduren Vererbung  echte Mehrfachvererbung wird meist vermieden Strategien zur Realisierung von Parametrisierung Hintergrund: Diskussionen um C++ Templates und Java Generic Tieferes Verständnis für das objektorientierte Paradigma & für die Realisierung in konkreten objektorientierten Sprachen 3. Zusammenfassung & Fazit

Vielen Dank für Eure Aufmerksamkeit!

Realisierung Mehrfachvererbung Zurück 2. Übersetzung // Vererbung

Mehrfachvererbung Beispiel: Nachricht im Pfad: GUIObjekt <- Figur <- Rechteck Aufruf im Parallel-Pfad: GUIObjekt <- Linie <- Rechteck Folgt Regeln der Polymorphie Aber: Programmierer hätte erwarten können, dass GUIObjekt::Zeichne() aufgerufen wird (falls Pfad nicht offen liegt – Teamarbeit, Bibliothek) Figur* f = new Rechteck(); f->Zeichne(); // Linie::Zeichne() auf Zurück 2. Übersetzung // Vererbung