• Bisher: prozedurale bzw. imperative Programmierung
  • Geprägt durch hierarchisches Aufrufen von Funktionen
  • Variablen (z.B. int, char), Datenstrukturen (struct) und Funktionen sind getrennt

• Modellierung

  • Anwendungsproblem \(\Rightarrow\) Modellierung \(\Rightarrow\) Reduzieren auf das „Wesentliche“

  • „Wesentlich“ im Sinne unserer Sicht auf die Dinge bei diesem Problem

    → Es existieren verschiedene Sichten auf dasselbe Problem!

• Objektorientierte Programmierung
  • Formulierung eines Modells in Konzepten und Begriffen der realen Welt
  • Nicht in computertechnischen Konstrukten (Hauptprogramm, Unterprogramm, Funktionen, …)
    • Stattdessen: Klassen (Objekte) mit Attributen und Methoden
    • Interaktion untereinander

• Pläne zur Beschreibung von abstrakten Objekt-Relationen

• Als Teil einer Klasse heißen …
  • Funktionen → Methoden
  • Variablen → Attribute

// Definition des Bauplans
class Punkt {
    double x;
    double y;
};

// Instanz: Initialisierung
Punkt p;

• Abkapselung von Informationen mit Schlüsselwörtern public und private
• Ziele:
  • Sauberer Zugriff auf Variablen
  • Verstecken von Informationen, die nicht öffentlich zugänglich sein sollen
• Compiler hilft bei der Durchsetzung

struct Punkt {
    double x;
    double y;
};
// Bisher erlaubt
Punkt p;
p.x = 2.0;

class Punkt {
    double x;
    double y;
};
// Compiler-Fehler
Punkt p;
p.x = 2.0;

• Grund für Compiler-Fehler: private wird bei Klassen automatisch gesetzt

class Punkt {
// private: implizit gesetzt
    double x;
    double y;
};

class Punkt {
private: // Äquivalent
    double x;
    double y;
};

struct Punkt {
// public: implizit gesetzt
    double x;
    double y;
};

struct Punkt {
public: // Äquivalent
    double x;
    double y;
};

• Konstruktoren haben eine Reihe von besonderen Eigenschaften:

class Punkt {
    double x;
    double y;
public:
    Punkt() {} // Default
    // Parametrisiert
    Punkt(double x, double y)
        : x(x), y(y) {}
};

• Wird bei jeder Klassendefinition automatisch eingefügt,

  falls kein anderer Konstruktor definiert wird

• Ist ein parameterloser Konstruktor

• Die folgenden beiden Definitionen sind identisch:

class Punkt {
    double x;
    double y;
public:
    Punkt() {} // Explizit genannt
};

class Punkt {
    double x;
    double y;
// public: // Automatisch eingefügt
//     Punkt() {}
};

• Initialisiert standardmäßig keine Member-Variablen
• Konsistente Initialisierung auf verschiedene Weisen möglich
• Hier: Durch Überschreiben des Konstruktors bzw. durch Inline-Zuweisungen

#include <iostream>
using std::cout;
class Punkt {
    double x = 1.0; // Inline
    double y = 1.0;
public:
    Punkt() {}
    double get_x() { return x; }
    double get_y() { return y; }
};
int main() {
    Punkt p;
    cout << p.get_x() << " " << p.get_y();
}

#include <iostream>
using std::cout;
class Punkt {
    double x;
    double y;
public:
    Punkt() { x = 2.0; y = 2.0; }
    double get_x() { return x; }
    double get_y() { return y; }
};
int main() {
    Punkt p;
    cout << p.get_x() << " " << p.get_y();
}

• Initialisierung der Member über eine separate Stelle im Code

• Eigenschaft: wird vor dem Body der Funktion ausgeführt

• Aufbau:

  <class name>(<function parameters>) : <initializer list> { <function body> }

class Punkt {
    double y;
    double x;
public:
    Punkt() : x(2.0), y(1.0) {}
    // Alternativ: Braced Init.
    Punkt() : x{2.0}, y{1.0} {}

    /* Restliche Implementierung */
};

• Bisher: Beliebige Anzahl von verschiedener Konstruktoren definieren
• Aber: Können wir Konstruktoren auch verbieten?

• Das Erzeugen und Initialisieren von Objekten ist jetzt bekannt
• Der durch Objekte belegte Speicher muss aber irgendwann auch wieder freigegeben werden
  • Für primitive Datentypen wie int, double geschieht dies automatisch
  • Aber: Komplexere Datentypen wie Zeiger müssen explizit wieder freigegeben werden
  • Gleiches gilt im Übrigen auch für von der Klasse gehaltene Ressourcen
    • Beispiele: Geöffnete Datei, aktive Datenbankverbindung
    • … oder was auch immer gerade benötigt wird

• Angenommen, folgender Code wird ausgeführt. Was wird passieren?

#include <iostream>

class DataHandle {
    void * data;
    int size_;
public:
    DataHandle() = delete;
    DataHandle(int size): size_(size) {
        data = malloc(size * sizeof(void*));
    }
    ~DataHandle() {
        std::cout << "Destructor called" << std::endl;
        free(data);
    }
};

int main() {
    DataHandle dh1{4};
    {
        DataHandle dh2 = dh1;
    }
}

class DataHandle {
    void * data;
    int size_;
public:
    ~DataHandle() {
        std::cout
            << "Destructor called"
            << std::endl;
        free(data);
    }
};

int main() {
    DataHandle dh1{4};
    {
        DataHandle dh2 = dh1;
    } // Destruktor dh2
}     // Destruktor dh1. BOOM

Deshalb gibt es den Copy-Konstruktor

• Copy-Konstruktor hat einen Parameter → Referenz auf Objekt
  • Beispiel: DataHandle(const DataHandle& d) {}
  • const verbietet Modifikation des Originals
  • Referenz → kein Copy-by-Value des Originals (aufwendig)

class DataHandle {
    void * data;
    int size_;
public:
    DataHandle(const DataHandle& d) : size_(d.size_) {
        data = malloc(d.size_);
        std::memcpy(data, d.data, d.size_);
    }
};

• Ist ein etwas fortgeschritttener Aspekt von C++
• Hier: Konzept verstehen, statt jedes technische Detail zu ergründen

• Zunächst ein abstraktes Beispiel: Staffellauf
• Dabei übergibt ein bisheriger Läufer (→ Objekt) einem neuen Läufer eine wichtige Ressource (→ Stab)

An dieser Stelle kommt der Move-Konstruktor ins Spiel!

• Ziel: effizientes Verschieben von Ressourcen von einer Instanz zu einer anderen

  • Beispiel Zeiger: Verschieben des Zeigerwerts zum neuen Objekt

  • Wichtig: Originales Objekt sollte danach keinen Zugriff mehr auf die Ressource haben

    → Bester Weg: Alter Zeiger wird nullptr

3 + 3; // Temp. Rvalue

Rvalues sollen hier nicht weiter interessieren!

#include <utility> // für std::move
DataHandle dh1("foo");
// Type-Casting auf DataHandle &&
// gefolgt von Konstruktor-Aufruf
DataHandle dh2(std::move(dh1));

• Irreführender Name, std::move bewegt eigentlich nichts

• Stattdessen nur Type-Casting zu Referenz auf Rvalue

  → DataHandle wird zu DataHandle &&

• Gecasteter Wert wird anschließend als Parameter im Konstruktor-Aufruf verwendet

• Move-Konstruktor hat grundsätzlich Ähnlichkeit zum Copy-Konstruktor

• Wichtiger Unterschied: Ressourcen beim alten Objekt unzugänglich machen

• Grund: Alte Objekte existieren nach Move weiterhin

  (und könnten prinzipiell auch Ressourcen manipulieren)

  class DataHandle {
    void * data;
    int size_;
  public:
    DataHandle(DataHandle && dh) : data(dh.data), size_(dh.size_) {
        dh.data = nullptr; // Zugangssperre
    }
    /* Restliche Implementierung */
  };

• Ist eine interessante Programmiertechnik: Resource Acquisition Is Initialization (RAII)
  • Möglich durch automatische Destruktoraufrufe bei Verlassen des Scopes
  • Ressourcen in diesem Kontext müssen vorher akquiriert werden
  • Beispiel: Öffnen einer Datei bzw. Datenbankverbindung
• Grundgedanke: Bei Konstruktor-Aufruf wird Ressource akquiriert, bei Destruktor-Aufruf automatisch wieder freigegeben
• Sehr praktisch: Speicherleck/Ressourcenleck wird dadurch unmöglich

• Situation: Automatisches Öffnen und Schließen einer Datei bei Initialisierung und Destruktor-Aufruf

#include <iostream>
#include <fstream>

using std::cout, std::endl;
using std::ios;

class FileHandler {
    std::fstream file; // File Handle
public:
    FileHandler(const std::string& filename) {
        file.open(filename, ios::in | ios::app);
        if (file.is_open()) {
            cout << "File opened successfully" << endl;
        }
    }
    ~FileHandler() {
        if (file.is_open()) {
            file.close();
            cout << "File closed" << endl;
        }
    }
    /* Implementierung (read(), write(), ...) */
};

int main() {
    cout << "main(): enter" << endl;
    {
        FileHandler fh("test.txt");
        /* Lese-/Schreiboperationen der Datei... */
    }
    cout << "main(): exit" << endl;
}

RAII ist eine extrem nützliche Programmiertechnik. Nutzt sie!

• Zeit für einen kurzen Zwischenstand:
  • Grundlegende Eigenschaften von Objekten wurden vorgestellt
  • Die grundlegende Reihenfolge der Initialisierung/Destruktion ebenso
  • Konstruktoren/Destruktoren sind jetzt bekannt
• Es fehlt: Smart Pointer (besseres Speicher-Management bei Zeigern)
  • Teil einer Reihe von Verbesserungen, die mit C++11 eingeführt wurden

Zunächst einmal kommen aber noch einige allgemeine Konzepte!

• Zur Erinnerung: C++ erlaubt das Überladen von Funktionen (und Konstruktoren)
• Außerdem: Operatoren könnnen auch überladen werden (Klassen/Strukturen)
  • Bereits bekannt: <<-Operator bei std::cout
  • std::cout << "Echo";
• Überladung mithilfe des Schlüsselworts operator
  • operator+=(int i); // Überlade += für int-Parameter
• Ist für die meisten Operatoren möglich, mit ein paar Ausnahmen:
  • . (bzw. .*) → Member-Zugriff (bzw. Member-Zugriff über Zeiger)
  • :: → Scope Resolution Operator
  • ?: → Ternärer Operator

• Beispiel: Wrapper-Klasse für Integer

#include <iostream>

class Integer {
    int val;
public:
    Integer() = delete;
    Integer(int i) : val(i) {}

    int operator+(int summand) { return val + summand; }
    void operator+=(int summand) { val += summand; }

    int value() { return val; }
};

int main() {
    Integer I{3};
    std::cout << "Sum: " << I + 5 << std::endl;
    I += 10;
    std::cout << "New value: " << I.value() << std::endl;
}

Operator-Überladung ist sehr nützlich, wenn es an den richtigen Stellen eingesetzt wird!

• Betrachtung einer wichtigen Regel in C++: Rule of Three/Five

• Rule of Three

  • Wenn es notwendig ist, einen eigenen Destruktor, Copy-Konstruktor, oder Copy-Assignment-Operator (operator=(const &)) zu erstellen, sollen* alle drei erstellt werden

• Rule of Five

  • Erweiterung der Rule of Three um Move-Konstruktor und Move-Assignment-Operator (operator=(&&))

• friend gestattet selektiven Zugriff für externe Klassen und Funktionen

  → friend ostream& operator<<(ostream& os, Punkt& p);

• Randbemerkung: Aufruf von externen Funktionen ohne Namespace-Präfix

#include <iostream>
using std::cout, std::endl;
using std::ostream;

class Punkt {
    double x;
    double y;
public:
    Punkt(double x, double y) : x(x), y(y) {}

    friend void print_punkt(Punkt& p);
    friend ostream& operator<<(ostream& os, Punkt& p);
};

ostream& operator<<(ostream& os, Punkt& p) { // Extern definiert
    cout << "Member: X=" << p.x << " Y=" << p.y << endl;
    return os;
}

void print_punkt(Punkt& p) {
    cout << "Member: X=" << p.x << " Y=" << p.y << endl;
}

int main() {
    Punkt p{1.5, 2.3};
    cout << "Ostream: \t" << p; // Jetzt erlaubt
    cout << "print_punkt: \t";
    print_punkt(p);
}

• Nur innerhalb einer Klasse verfügbar
• Zeiger auf die aktuelle Instanz der Klasse (wird automatisch erzeugt)

class Integer {
    int val;
public:
    Integer(int i) : val(i) {}

    int value() {
        return val; // Implizit
    }
    int value_explicit() {
        return this->val;
    }
};

• Member dürfen als static deklariert werden
• Gehören keinem Objekt an, sondern der Klasse selbst

#include <iostream>

using std::cout, std::endl;

class A {
public:
    static int _count;
    A() { _count++; }
    ~A() { _count--; }
    static int count() { return _count; }
};
int A::_count = 0; // Initialisierung *außerhalb* der Klasse in *.cpp-Datei

int main() {
    A a1, a2;
    {
        cout << A::count() << endl;
        A a3;
        cout << A::count() << endl;
    }
    cout << A::count();
    return 0;
}

• new und delete haben die gleichen Schwächen wie free und malloc 🙁
• Syntax ist jetzt etwas angenehmer
• Aber: Programmierer:in kann immer noch Aufrufe vergessen

• Seit C++11 Bestanteil des Standards
• Objekte kapseln Zeigervariable
• Verwenden dazu im Kern das RAII-Idiom
• Zwei wichtige Typen
  • unique_ptr
  • shared_ptr
• Klassische Zeiger werden oft als Raw Pointer bezeichnet

• Benutzung von Unique Pointer ist sehr einfach

  → Deklaration: std::unique_ptr<int> i_ptr; // Zeiger auf int *

#include <memory> // std::unique_ptr
using std::unique_ptr;
using std::make_unique;

// Erstellt neuen int *
// Wert des derefenzierten int* ist 5
unique_ptr<int> i_ptr = make_unique<int>(5);

int i = *i_ptr + 3; // 8

#include <memory> // std::unique_ptr
using std::unique_ptr;

class Foo{ /* */ };

int main() {
    Foo * f = new Foo();
    unique_ptr<Foo> f_ptr(f);
} // f_ptr ruft delete

• Dank Operator-Überladung Zugriff auf gekapselten Zeiger

unique_ptr<int> i_ptr = make_unique<int>(5);

int i = *i_ptr + 3; // 8

class Foo {
public:
    void bar() {}
}

unique_ptr<Foo> f_ptr = make_unique<Foo>();

f_ptr->bar();

#include <memory>
#include <iostream>

using std::unique_ptr;
using std::cout, std::endl;

class Foo {
public:
    Foo() { cout << "Foo constructor called\n"; }
    ~Foo() { cout << "Foo destructor called\n"; }

    void print() { cout << "Hello Foo\n"; }
};

int main() {
    cout << "main(): Enter" << endl;
    Foo * f = new Foo();
    {
        cout << "Scope: Enter" << endl;
        unique_ptr<Foo> f_ptr(f); // Konstruktoraufruf, Übernahme von f
        f_ptr->print();
        cout << "Scope: Exit" << endl;
    } // delete f
    cout << "main(): Exit" << endl;
}

Unique Pointer sind deutlich besser als händisches Verwalten! Nutzt sie, wenn ihr könnt.

class SharedPtr { // Vereinfachte Darstellung
private:
    int * ptr;
    int counter = 1;
public:
    SharedPtr(SharedPtr& cpy) { ++counter; }
    ~SharedPtr() {
        --counter;
        if (counter == 0)
            delete ptr;
    }
}

• Bei Aufrufen des Destruktors wird dieser Zähler dekrementiert
  • Erst wenn Zähler Wert 0 annimmt, wird der gehaltene Zeiger zerstört
• Achtung: Zum Teilen von Membern in verschiedenen Klassen gedacht
  • Aber: Widerspricht dem Grundgedanken der sauberen Kapselung durch Klassen

Überdenkt euer Design, falls der Einsatz von shared_ptr jemals notwendig erscheinen sollte shared_ptr ist hauptsächlich für nebenläufige Programmierung gedacht!

• Idee hinter Shared Pointer: Zählen von Referenzen
• Gibt es auch in anderen Programmiersparchen: z.B. Java, Python, C#, Javascript
• Keine automatischen Destruktor-Aufrufe vorhanden wie in C++
• Stattdessen: Konzept namens Garbage Collection
  • Dazu wird für jedes Objekt zusätzlich ein Referenzenzähler angelegt
• Ausführungsumgebung (Runtime) pausiert die Ausführung regelmäßig und zählt
  • Falls ein Zähler den Wert 0 hat, wird das zugehörige Objekt entfernt
  • Das Programm steht in der Zwischenzeit!
    • Natürlich deutlich langsamer als in C++ (Je nach Sprache 1-2 Größenordnungen)
    • Dafür muss der Programmierer sich aber keine Gedanken über Speichermanagement machen

• Aufbau von Klassen
  • Sichtbarkeitsmodifikatoren
  • Konstruktoren (Copy, Move, …)
  • Destruktoren
• Konzept der Operator-Überladung
• Resource Acquisition Is Initialization
• Dynamische Speicherallokation(new / delete)
• Smart Pointer