Ownership

Das Problem, das Ownership löst

Programmiersprachen haben über die letzten 50 Jahre drei große Lösungen für Memory-Management entwickelt:

• Manuelle Verwaltung (C, C++): malloc/free, new/delete. Der Programmierer ist verantwortlich. Nachteil: Use-after-Free, Double-Free und Memory-Leaks sind ständige Fehlerquellen. Microsoft- und Chromium-Studien zeigen 60–70 % aller sicherheitskritischen Bugs als Memory-Issues.
• Garbage Collection (Java, Go, JavaScript, Python): eine Runtime räumt nicht mehr referenzierten Speicher auf. Nachteil: GC-Pausen, weniger Kontrolle über Speicher-Layout, höhere Laufzeit-Kosten.
• Reference Counting (Swift, früher Objective-C): jeder Wert weiß, wie oft er referenziert wird. Nachteil: Zyklen brechen das Schema, atomare Zähler-Operationen kosten.

Ownership ist die vierte große Antwort: Compile-Zeit-Beweis, dass alle Speicher-Operationen sicher sind. Keine Runtime, keine GC-Pausen, keine Zähler. Der Compiler verfolgt, welcher Code-Pfad welchen Wert wann besitzt — und lässt nichts durch, was die Regeln verletzt.

Die Kernidee in einem Satz

Jeder Wert hat genau einen Besitzer. Wenn der Besitzer den Scope verlässt, wird der Wert freigegeben.

Aus dieser einen Regel ergeben sich alle weiteren:

• Wert wird zugewiesen → Besitz wandert (Move) oder Wert wird kopiert (Copy).
• Wert wird in eine Funktion übergeben → Besitz wandert in die Funktion oder Borrow wird gegeben.
• Wert verlässt einen Scope → Wert wird gedroppt, Heap-Speicher freigegeben, File-Handle geschlossen, Lock freigegeben.

Diese Mechanik wird vom Borrow Checker zur Compile-Zeit überprüft. Er liest dein Programm Zeile für Zeile und prüft jeden Move, jede Borrow, jedes Drop. Das Resultat ist eine Sprache, die so schnell ist wie C, aber so sicher wie Haskell.

Was dich erwartet

• Ownership-Regeln — die drei formalen Regeln, wie der Compiler sie anwendet, erste Beispiele mit detaillierter Compiler-Diagnostik.
• Move-Semantik — was genau bei let y = x; passiert, wenn x nicht Copy ist. Wann werden Werte gemoved, was bedeutet das im Speicher, und wie wirkt der Move auf folgende Code-Zeilen?
• Copy-Trait und Clone — der Copy-Trait als Marker für triviale Bit-Kopien, Clone als explizit aufgerufene Duplizier-Methode. Wann darf ein Typ Copy sein, wann ist Clone die richtige Wahl, und wann sollte man bewusst keines von beiden implementieren?
• Drop-Trait — wann wird drop automatisch aufgerufen, wie sieht eine eigene Drop-Implementierung aus, und warum ist deterministisches Drop das Fundament der RAII-Patterns für File-Handles, Mutex-Guards und Datenbank-Transaktionen.
• Funktionsparameter und Ownership — wie verhalten sich Move und Borrow bei Funktions-Calls, welche Patterns sind idiomatisch, und wann braucht man explizite Rückgabe von Werten zum Aufrufer.
• Stack vs. Heap — das mentale Modell für Speicher-Layout. Was lebt auf dem Stack, was auf dem Heap, wie sieht ein String und Vec<T> intern aus, und wann ist Box<T> die richtige Wahl?

Was du nach diesem Kapitel kannst

• Die drei Ownership-Regeln aus dem Stand erklären — und sie an konkreten Code-Beispielen anwenden.
• Move-Semantik erkennen — du siehst auf einen Blick, ob eine Operation einen Wert verschiebt oder kopiert.
• Den Unterschied zwischen Copy und Clone benennen, und für eigene Typen die richtige Wahl treffen.
• Drop-Reihenfolge für komplexe Code-Pfade mental nachvollziehen.
• Funktions-Signaturen so entwerfen, dass Aufrufer maximale Flexibilität haben (Borrow vor Move, soweit möglich).
• Compiler-Fehler wie E0382 (use of moved value), E0507 (cannot move out of borrowed content) und E0382 (borrow after move) sicher lesen und beheben.
• Stack-vs-Heap-Entscheidungen bewusst treffen.

Nach diesem Kapitel kommt die natürliche Fortsetzung: References & Borrowing — die Mechanismen, mit denen du Werte teilst, ohne Ownership zu übergeben. Beides zusammen bildet das Fundament für Lifetimes, Traits, Smart Pointers und schließlich asynchrone Programmierung.

Eine erste Vorschau

Bevor wir tiefer einsteigen, hier ein kompletter Mini-Lauf durch alle Konzepte des Kapitels — das soll keine vollständige Erklärung sein, sondern einen Eindruck davon, was kommt:

struct Datei {
    name: String,
    inhalt: Vec<u8>,
}

impl Drop for Datei {
    fn drop(&mut self) {
        println!("Drop: {}", self.name);    // Cleanup beim Scope-Ende
    }
}

fn verarbeiten(d: Datei) -> usize {
    // d wurde HIERHIN gemoved — der Aufrufer hat ihn nicht mehr
    d.inhalt.len()
}   // d wird hier gedroppt

fn main() {
    let d = Datei {
        name: String::from("log.txt"),
        inhalt: vec![1, 2, 3, 4, 5],
    };
    let len = verarbeiten(d);
    // println!("{}", d.name);   // Fehler — d wurde gemoved
    println!("Länge war: {len}");
}

In diesen 20 Zeilen sind alle Kern-Themen versteckt:

• Eine Datei wird konstruiert — sie besitzt einen heap-allozierten String und einen Vec<u8>.
• Beim Aufruf verarbeiten(d) wird die gesamte Datei in die Funktion gemoved — d ist im main-Scope nicht mehr nutzbar.
• Am Ende von verarbeiten wird d automatisch gedroppt — der eigene Drop-Impl läuft, dann werden String und Vec<u8> gedroppt.
• Heap-Allokationen werden freigegeben — ohne Garbage Collection, ohne expliziten free-Aufruf.

Wer das vollständig versteht — und wann Move passiert, wann Copy, wann Drop — hat Ownership im Griff.

Weiterführende Ressourcen

Externe Quellen

• The Rust Book – Ownership
• Rust Reference – Ownership and lifetimes
• The Rustonomicon – Ownership
• Rust by Example – Ownership

Verwandte Artikel

• Ownership-Regeln
• Move-Semantik
• Copy-Trait und Clone
• Drop-Trait
• Funktionsparameter und Ownership
• Stack vs. Heap