Rust on kenji.blog

Erklärung von 'Ownership' und 'Borrowing' in Rust im Vergleich zu C++ Zeigern

Sat, 12 Sep 2026 04:00:00 +0900

In der modernen Systemprogrammierung ist die Vereinbarkeit von Leistung und Speichersicherheit eine ständige Herausforderung. C++ war lange Zeit der unangefochtene König in diesem Bereich, aber in den letzten Jahren hat Rust begonnen, diese Position zu bedrohen. Das größte Merkmal von Rust ist die Garantie der Speichersicherheit zur Kompilierzeit ohne Garbage Collection (GC), was durch die Konzepte von “Ownership” (Eigentum) und “Borrowing” (Ausleihen) erreicht wird.

In diesem Artikel werden wir C++ Zeiger (rohe Zeiger, std::unique_ptr, std::shared_ptr) und das Rust-Ownership-Modell detailliert vergleichen. Wir werden anhand von Codebeispielen und Diagrammen ausführlich erklären, wie der Rust-Compiler (Borrow Checker) Use-After-Free (Verwendung nach Freigabe) und Datenrennen (Data Races) verhindert.

1. Grundlagen der Speicherverwaltung: Stack und Heap

Um die Grundlagen der Speicherverwaltung zu verstehen, lassen Sie uns zunächst einen Blick darauf werfen, wie Programme den Speicher nutzen. Der Speicherbereich wird grob in “Stack” und “Heap” unterteilt.

Stack

Dies ist der Bereich, in dem lokale Variablen bei Funktionsaufrufen abgelegt werden. Er hat eine LIFO-Struktur (Last-In-First-Out) und die Speicherzuweisung und -freigabe ist sehr schnell. Hier werden nur Daten platziert, deren Größe zur Kompilierzeit bestimmt werden kann.

Heap

Hier werden Daten platziert, deren Größe zur Laufzeit dynamisch bestimmt wird, oder Daten, die über den Gültigkeitsbereich einer Funktion hinaus existieren müssen. Auf sie wird über Zeiger (oder Referenzen) zugegriffen.

In C++ und Rust, die keine Garbage Collection haben, kann der Verwaltungsaufwand für den Heapspeicher als Formel wie folgt modelliert werden. Wenn die Gesamtzahl der Objekte $N$ ist, die durchschnittliche Zeit für die Allokation $T_{alloc}$ und die durchschnittliche Zeit für die Deallokation $T_{dealloc}$ ist, dann ist der Gesamtaufwand für die Speicherverwaltung $C_{memory}$:

$$ C_{memory} = \sum_{i=1}^{N} (T_{alloc, i} + T_{dealloc, i}) + O_{sync} $$

Hierbei ist $O_{sync}$ der Overhead für die gegenseitige Ausschließung (Mutex- oder atomare Operationen) in einer Multithread-Umgebung. Da Rust den Zeitpunkt der Speicherfreigabe zur Kompilierzeit bestimmt, führt es $T_{dealloc}$ zu einem zuverlässigen und sicheren Zeitpunkt aus, während die Durchsatzminderung (Stop-The-World) durch die Garbage Collection zur Laufzeit auf null reduziert wird.

graph TD A["Programmspeicher"] --> B["Stack (Schnell, Feste Größe)"] A --> C["Heap (Dynamisch, Langsamer)"] B --> D["Lokale Variablen"] B --> E["Zeiger/Referenzen"] C --> F["Dynamisch zugewiesene Daten"] E -.->|"Zeigt auf"| F

2. C++ Zeiger: Der Kompromiss zwischen Freiheit und Gefahr

Werfen wir einen Blick auf die Entwicklung der Speicherverwaltung in C++.

Die Ära der rohen Zeiger (Raw Pointers) und ihre Probleme

Rohe Zeiger (*), die von der Sprache C übernommen wurden, bieten ultimative Freiheit, sind aber gleichzeitig eine Brutstätte für die folgenden schwerwiegenden Bugs:

Speicherleck (Memory Leak): Vergessen, mit new zugewiesenen Speicher mit delete freizugeben.
Hängender Zeiger (Dangling Pointer): Zugriff auf einen Zeiger nach der Speicherfreigabe (nach delete).
Doppelte Freigabe (Double Free): Zweimaliges Aufrufen von delete für denselben Speicherbereich.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// C++: Beispiel für Probleme mit rohen Zeigern
void rawPointerExample() {
 int* ptr = new int(10);
 // ... Irgendeine Verarbeitung ...
 delete ptr;

 // Versehentlicher erneuter Zugriff (Use-After-Free / Dangling Pointer)
 // Der C++-Compiler kann dies nicht als Kompilierfehler erkennen
 std::cout << *ptr << std::endl; // Undefiniertes Verhalten (Undefined Behavior)
}

Die Einführung von RAII und Smart Pointern (ab C++11)

Seit C++11 wurden Smart Pointer, die auf dem RAII-Konzept (Resource Acquisition Is Initialization) basieren, standardisiert, und die direkte Verwendung von rohen Zeigern wird nicht mehr empfohlen.

`std::unique_ptr`

Ein Zeiger, der exklusives Eigentum (Ownership) ausdrückt. Der Speicher wird automatisch freigegeben, wenn der Gültigkeitsbereich (Scope) verlassen wird. Er kann nicht kopiert werden; nur das “Verschieben” (Move) des Eigentums ist möglich (unter Verwendung von std::move).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// C++: std::unique_ptr
#include <memory>
#include <iostream>

void uniquePtrExample() {
 std::unique_ptr<int> p1 = std::make_unique<int>(42);
 // std::unique_ptr<int> p2 = p1; // Kompilierfehler (Kopieren nicht möglich)
 std::unique_ptr<int> p3 = std::move(p1); // Verschieben des Eigentums

 // Schwäche von C++: Nach dem Move wird p1 zu nullptr, aber der Zugriff selbst ist kompilierbar
 // Führt zur Laufzeit zu einem Absturz (Segmentation Fault)
 // std::cout << *p1 << std::endl;
}

`std::shared_ptr`

Ein Zeiger, der es mehreren Zeigern ermöglicht, dasselbe Objekt zu teilen. Er verwendet Referenzzählung (Reference Counting), um den Speicher freizugeben, wenn der Zähler 0 erreicht. Da atomare Inkrementierungs- und Dekrementierungsoperationen erforderlich sind, entsteht ein gewisser Leistungs-Overhead (entsprechend dem oben genannten $O_{sync}$).

3. Rusts Ownership (Eigentum): Ein Paradigmenwechsel

Rust hat das Konzept von std::unique_ptr aus C++ als Kern seiner Sprachspezifikation übernommen und verfügt über ein noch strengeres “Ownership-Modell”.

Die 3 Regeln von Ownership

Das Ownership-System von Rust basiert auf den folgenden drei sehr einfachen Regeln:

Jeder Wert in Rust hat eine Variable, die als sein Eigentümer (Owner) bezeichnet wird.
Es kann immer nur einen Eigentümer zur gleichen Zeit geben.
Wenn der Eigentümer den Gültigkeitsbereich (Scope) verlässt, wird der Wert verworfen.

In Rust werden Ressourcen standardmäßig “verschoben” (moved). Das Eigentum wird durch Zuweisungsoperationen verschoben, ohne dass std::move wie in C++ explizit angegeben werden muss.

1
2
3
4
5
6
7
8


// Rust: Verschieben des Eigentums (Move)
fn main() {
 let s1 = String::from("hello"); // Daten, die auf dem Heap allokiert werden
 let s2 = s1; // Das Eigentum wird von s1 auf s2 verschoben (moved)

 // Der größte Unterschied zu C++: Der Zugriff auf eine Variable nach dem Move führt zu einem "Kompilierfehler"!
 // println!("{}, world!", s1); // Kompilierfehler: value borrowed here after move
}

Diese Funktion, den Zugriff auf Variablen nach einem Move zur Kompilierzeit zu verhindern, ist einer der Gründe, warum Rust sicherer ist als std::unique_ptr in C++.

sequenceDiagram participant S1 as "Variable s1" participant Heap as "Heap-Speicher ('hello')" participant S2 as "Variable s2" S1->>Heap: "Weist zu & Besitzt" Note over S1,S2: "let s2 = s1;" S1--xHeap: "Verliert Eigentum (Ungültig)" S2->>Heap: "Übernimmt Eigentum"

4. Borrowing (Ausleihen) und Referenzen

Wenn man das Eigentum ständig verschiebt, müsste man es jedes Mal zurückgeben lassen, wenn man einen Wert an eine Funktion übergibt, was sehr unpraktisch ist. Hier kommt das “Borrowing” (Ausleihen) ins Spiel. Es entspricht Zeigern oder Referenzen in C++.

In Rust gibt es zwei Arten von Borrowing:

Unveränderliche Referenz (Immutable Reference): &T (ähnlich wie const T& in C++)
Veränderliche Referenz (Mutable Reference): &mut T (ähnlich wie T& in C++)

Die unerbittlichen Regeln des Borrow Checkers

Der Rust-Compiler enthält einen “Borrow Checker”, der die Gültigkeit von Referenzen überprüft. Der Borrow Checker erzwingt die folgenden strengen Regeln:

In jedem beliebigen Gültigkeitsbereich kann nur eine der folgenden Bedingungen existieren:

Genau eine veränderliche Referenz (&mut T)

Mehrere unveränderliche Referenzen (&T)

Dies wird als das Prinzip “Multiple Readers XOR Single Writer (MRSW)” bezeichnet. Es kann durch ein mathematisches exklusives ODER (XOR) ausgedrückt werden. Für einen Zustand $S$ müssen die Anzahl der unveränderlichen Referenzen $N_r$ und die Anzahl der veränderlichen Referenzen $N_w$ die folgende Einschränkung erfüllen:

$$ (N_r \ge 0 \land N_w = 0) \oplus (N_r = 0 \land N_w = 1) $$

Diese Regel eliminiert Datenrennen (Data Races) zur Kompilierzeit vollständig. Ein Datenrennen tritt auf, wenn ① zwei oder mehr Zeiger gleichzeitig auf dieselben Daten zugreifen, ② mindestens einer davon schreibt und ③ kein Synchronisationsmechanismus vorhanden ist. Rust verhindert Datenrennen im Vorfeld, indem es die Bedingung ② zur Kompilierzeit bricht.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Rust: Kompilierfehler durch Verletzung der Borrowing-Regeln
fn main() {
 let mut s = String::from("hello");

 let r1 = &s; // Unveränderliches Ausleihen (OK)
 let r2 = &s; // Unveränderliches Ausleihen (OK)
 // let r3 = &mut s; // Fehler! Es kann keine veränderliche Referenz erstellt werden, solange unveränderliche Referenzen existieren

 println!("{}, {}", r1, r2);
}

5. Verhinderung der Iterator-Ungültigmachung (Iterator Invalidation)

Als konkretes Beispiel, bei dem die Leistungsfähigkeit des Borrow Checkers am deutlichsten wird, betrachten wir den klassischen Bug der “Iterator-Ungültigmachung”.

Iterator-Ungültigmachung in C++ (Laufzeitabsturz)

Wenn ein std::vector in C++ innerhalb einer Schleife geändert wird, besteht die Möglichkeit, dass der dahinterliegende Speicher neu zugewiesen (reallocated) wird, wodurch Referenzen zu hängenden Zeigern (Dangling Pointers) werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// C++: Bug der Iterator-Ungültigmachung
#include <iostream>
#include <vector>

int main() {
 std::vector<int> v = {1, 2, 3};

 // Referenz auf das Element des Vektors abrufen
 int& first = v[0];

 // Element hinzufügen (Wenn die Kapazität hier nicht ausreicht, wird ein neuer Speicherbereich zugewiesen,
 // und der alte Bereich könnte verworfen werden)
 v.push_back(4);

 // first könnte auf bereits freigegebenen Speicher zeigen! (Undefiniertes Verhalten)
 std::cout << "The first element is: " << first << std::endl;

 return 0;
}

Schutz zur Kompilierzeit durch Rust

Lassen Sie uns genau dieselbe Logik in Rust schreiben.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Rust: Iterator-Ungültigmachung zur Kompilierzeit verhindern
fn main() {
 let mut v = vec![1, 2, 3];

 // Unveränderliche Referenz abrufen (Beginn des Ausleihens)
 let first = &v[0];

 // Fehler! Solange `first` `v` unveränderlich ausleiht,
 // kann die für `v.push` erforderliche veränderliche Referenz nicht erstellt werden.
 // v.push(4);

 println!("The first element is: {}", first);
}

Da Rust auf Compiler-Ebene verbietet, “einen Wert zu ändern (veränderlich auszuleihen), während er gelesen wird (unveränderlich ausgeliehen ist)”, werden fatale Bugs wie Use-After-Free oder Iterator-Ungültigmachung zur Kompilierzeit zuverlässig abgefangen.

graph LR A["Variable v (Eigentümer)"] --> B["Heap Array [1, 2, 3]"] C["Referenz 'first' (&v[0])"] -.->|"Unveränderliches Ausleihen"| B A -->|X "Veränderliches Ausleihen verweigert!"| D["v.push(4)"] style C stroke:#00FF00,stroke-width:2px style D stroke:#FF0000,stroke-width:2px

6. Geteiltes Eigentum (Shared Ownership) in Rust: `Rc` und `Arc`

Geteiltes Eigentum, das dem std::shared_ptr in C++ entspricht, ist auch in Rust verfügbar, jedoch gibt es eine klare Typentrennung für Single-Threaded- und Multi-Threaded-Anwendungen.

Für Single-Thread: `Rc<T>` (Reference Counted)

Rc<T> ist ein nicht-thread-sicherer Smart Pointer mit Referenzzählung. Da er Inkrementierungs- und Dekrementierungsoperationen ohne atomare Befehle durchführt, ist er innerhalb eines einzelnen Threads sehr schnell. Wenn Sie jedoch versuchen, ihn an einen anderen Thread zu senden, führt dies zu einem Kompilierfehler (da er das Send-Trait nicht implementiert).

Für Multi-Thread: `Arc<T>` (Atomic Reference Counted)

Wenn Daten zwischen Threads geteilt werden sollen, wird Arc<T> verwendet, das atomare Inkrementierungen und Dekrementierungen durchführt. Es verursacht vergleichbare Kosten wie std::shared_ptr in C++.

Darüber hinaus tritt in C++ ein Datenrennen auf, wenn mehrere Threads gleichzeitig in eine von std::shared_ptr gemeinsam genutzte Variable schreiben. Um dies zu verhindern, muss std::mutex manuell und korrekt verwendet werden.

Im Gegensatz dazu kann in Rust die innere Struktur von Arc<T> allein nicht geändert werden. Wenn Änderungen erforderlich sind, muss es mit einem Mutex, d. h. Mutex<T>, kombiniert werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // Kombination aus thread-sicherem Teilen und gegenseitigem Ausschluss
 // Ähnlich wie std::shared_ptr<std::mutex> in C++, aber der Mutex kapselt die Daten
 let counter = Arc::new(Mutex::new(0));
 let mut handles = vec![];

 for _ in 0..10 {
 let counter_clone = Arc::clone(&counter);
 let handle = thread::spawn(move || {
 // Erst durch den Aufruf von lock() erhält man die veränderliche Referenz (&mut i32) auf das Innere
 let mut num = counter_clone.lock().unwrap();
 *num += 1;
 }); // Die Freigabe der Sperre (Lock) erfolgt automatisch durch RAII beim Verlassen des Gültigkeitsbereichs
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }

 println!("Result: {}", *counter.lock().unwrap());
}

Bemerkenswert ist, dass Mutex<T> in Rust nicht nur ein einfacher Sperrmechanismus ist, sondern “die zu schützenden Daten als Typ kapselt”. Dies verhindert auf Compiler-Ebene vollständig den Fehler, “auf Daten zuzugreifen und dabei zu vergessen, die Sperre zu erlangen”. Es ist so konzipiert, dass man ohne das Erlangen der Sperre (lock()) keine Zugriffsrechte (Referenz) auf die darin enthaltenen Daten erhält.

Fazit: “Vorabprüfung” durch den Compiler oder “Eigenverantwortung” durch den Entwickler

Zeiger und Smart Pointer in C++ bieten Entwicklern ein hohes Maß an Kontrolle und Leistung, aber ihre korrekte Verwendung hängt von der Disziplin des Entwicklers ab. Obwohl C++ durch die Einführung von RAII und std::unique_ptr drastisch sicherer geworden ist, kann es “undefiniertes Verhalten” wie den Zugriff nach einem Move oder die Iterator-Ungültigmachung auf Sprachebene nicht vollständig verhindern.

Auf der anderen Seite erkennt Rust diese Fehler zur Kompilierzeit anstatt zur Laufzeit, indem es die Regeln von “Ownership” und “Borrowing” in den Compiler integriert. Die starke Garantie, dass “wenn es kompiliert, speichersicher ist”, ist der Hauptgrund, warum Rust in der Systemprogrammierung schnell an Popularität gewinnt.

Der Kampf mit dem Borrow Checker von Rust (“Fighting the borrow checker”) ist für Anfänger eine große Hürde, aber letztendlich übernimmt der Compiler nur streng die komplexe Berechnung der “Verfolgung der Lebensdauer von Zeigern”, die C++ Programmierer ursprünglich in ihren Köpfen durchführten.

Wenn man Rust lernt, nachdem man die Freiheit und die Gefahren von C++ Zeigern verstanden hat, wird man die Philosophie hinter dem Ownership-Modell und das “Warum es so entworfen wurde” tiefgründiger verstehen können.

Dieser Artikel ist eine vergleichende Betrachtung der Speicherverwaltungsmethoden in C++ und Rust. Wir hoffen, dass er als Referenz für die Auswahl der geeigneten Sprache entsprechend den Anforderungen des jeweiligen Projekts dient.

Vorteile und Nachteile von Rust aus der Sicht eines C++-Entwicklers

Sat, 12 Sep 2026 03:00:00 +0900

Einführung: Eine neue Morgenröte in der Systemprogrammierung

In der modernen Softwareentwicklung sind C++ und Rust die zwei großen Giganten, die an vorderster Front der Systemprogrammierung stehen. Viele Jahre lang herrschte C++ als absoluter König in Bereichen, in denen extreme Hardwareleistung gefordert ist, wie Betriebssysteme, eingebettete Geräte, Spiele-Engines und Hochfrequenzhandel (HFT). Ich selbst schreibe als Senior-C++-Entwickler seit der C++98-Ära mit ihrem Dschungel aus rohen Zeigern Code und habe die Welle der Modernisierung durch C++11 (Einführung von Smart Pointern, Lambda-Ausdrücken und auto) sowie die kontinuierliche Vergrößerung der Spezifikationen in C++14/17/20 hautnah miterlebt.

In den letzten Jahren hat Rust jedoch als Lösung für die strukturellen Probleme von C++ – insbesondere das “Fehlen von Speichersicherheit”, das zu Sicherheitslücken führt (etwa 70% der CVEs sollen speicherbedingt sein), und die “endlos komplexen Spezifikationen sowie undefiniertes Verhalten (UB)” – einen dramatischen Aufstieg erlebt. Die offizielle Einführung in den Linux-Kernel sowie groß angelegte Migrationsprojekte zu Rust durch Tech-Giganten wie Microsoft, Google und AWS sind nicht nur ein vorübergehender Trend, sondern bedeuten einen Paradigmenwechsel in der Systemprogrammierung.

In diesem Artikel werde ich die “Vorteile” und “Nachteile”, die ich als waschechter C++-Entwickler beim tiefgreifenden Erlernen und praktischen Einsatz von Rust erfahren habe, aus einer technischen Perspektive, die an die Grundlagen des Sprachdesigns rührt, gründlich vergleichen und erläutern.

1. Paradigmenwechsel in der Speicherverwaltung: Von RAII zu Ownership und Borrowing

Die Grenzen von RAII und Smart Pointern in C++

Eine der größten Erfindungen von C++ ist RAII (Resource Acquisition Is Initialization). Dieses Konzept, bei dem Ressourcen im Konstruktor gesichert und beim Verlassen des Gültigkeitsbereichs (Scope) im Destruktor automatisch freigegeben werden, befreite Entwickler von der Angst vor Speicherlecks durch manuelles new und delete. Seit C++11 wurden std::unique_ptr und std::shared_ptr in die Standardbibliothek eingeführt, wodurch das Konzept der Eigentümerschaft (Ownership) im Code darstellbar wurde.

Allerdings haben die Smart Pointer und die Move-Semantik von C++ eine fatale Schwäche: Die statische Überprüfung durch den Compiler ist unvollständig.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


#include <iostream>
#include <memory>
#include <string>

void consume(std::unique_ptr<std::string> ptr) {
 std::cout << "Consuming: " << *ptr << std::endl;
}

int main() {
 auto my_ptr = std::make_unique<std::string>("Hello, C++");

 // Eigentümerschaft an die Funktion übertragen (Move)
 consume(std::move(my_ptr));

 // Gefahr: In C++ führt der Zugriff auf das Objekt nach dem Move nicht zu einem Kompilierungsfehler.
 // std::move ist nur ein Cast zu einer R-Value-Referenz (T&&) und der Compiler blockiert die Nutzung nicht.
 if (my_ptr) {
 std::cout << "Pointer is still valid?" << std::endl;
 } else {
 std::cout << "Pointer is null." << std::endl;
 }

 // std::cout << *my_ptr << std::endl; // Undefiniertes Verhalten durch Nutzung nach Freigabe (Use-After-Free)
 return 0;
}

In C++ besteht immer das Risiko, versehentlich auf ein Objekt zuzugreifen, das durch std::move entleert wurde (ein gültiger, aber unspezifizierter Zustand). Dies führt unmittelbar zu Abstürzen zur Laufzeit oder im schlimmsten Fall zu Sicherheitslücken.

Rusts Eigentümerschaft (Ownership) und die absolute Verteidigung des Borrow Checkers

Rust hat dieses Konzept der “Eigentümerschaft” in das Kerndesign der Sprache integriert und führt durch eine Compiler-Funktion namens Borrow Checker eine strenge statische Analyse durch.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


fn consume(s: String) {
 println!("Consuming: {}", s);
} // Hier verlässt s den Scope und der Speicher wird freigegeben (Drop)

fn main() {
 let my_string = String::from("Hello, Rust");

 // Eigentümerschaft wird an die Funktion gemovet. In Rust ist Move-Semantik der Standard.
 consume(my_string);

 // Kompilierungsfehler! Auf eine Variable nach einem Move kann unter keinen Umständen mehr zugegriffen werden
 // println!("Is it still there? {}", my_string);
}

Wenn in Rust die Eigentümerschaft einer Variablen verschoben wird, behandelt der Compiler die ursprüngliche Variable so, als wäre sie “uninitialisiert”, und blockiert jeglichen weiteren Zugriff vollständig. Dadurch können Fehler wie “Use-After-Free” oder “Dangling Pointers” theoretisch nicht durch die Kompilierung gelangen.

graph TD A["C++ std::unique_ptr"] --> B["std::move angewendet"] B --> C["Eigentümerschaft übertragen"] C --> D["Alter Zeiger weiterhin zugänglich"] D --> E["Potenzielles undefiniertes Verhalten (UB)"] F["Rust Box / String"] --> G["Als Wert übergeben (Move)"] G --> H["Eigentümerschaft übertragen"] H --> I["Compiler blockiert alte Variable"] I --> J["Speichersicherheit garantiert"]

Ausleihen (Borrowing) und die Kontrolle der Veränderbarkeit

Noch leistungsfähiger sind die Regeln für das “Ausleihen (Borrowing)”, bei dem eine Referenz auf eine Ressource erstellt wird. In Rust werden folgende Regeln erzwungen:

Zu einem beliebigen Zeitpunkt darf entweder “mehrere unveränderliche Referenzen (&T)” oder “genau eine veränderliche Referenz (&mut T)” existieren, aber nicht beides gleichzeitig.
Eine Referenz darf nicht länger leben als die Daten, auf die sie verweist (Lebensdauer-Beschränkungen / Lifetimes).

In C++ können problemlos mehrere veränderliche Referenzen oder Zeiger auf dasselbe Objekt erstellt werden, was zu unerwarteter Zerstörung des Zustands (wie Invalidation von Iteratoren) führen kann. Rust verhindert solche Fehler im Vorfeld, indem es die Kombination aus “Aliasing” und “Mutability” (Veränderbarkeit) auf Sprachebene verbietet.

2. Speicherlayout und der mathematische Overhead von Smart Pointern

In der Systemprogrammierung ist ein genaues Verständnis des Speicherlayouts unerlässlich. Vergleichen wir std::shared_ptr in C++ mit std::rc::Rc / std::sync::Arc in Rust.

Der C++ std::shared_ptr verwaltet Ressourcen über Referenzzählung, verwendet aber standardmäßig threadsichere atomare Operationen (std::atomic), um den Referenzzähler zu erhöhen oder zu verringern. Dieser Overhead im Speicher kann wie folgt formuliert werden:

$$ Overhead_{C++} = sizeof(T) + sizeof(ControlBlock) $$

Hierbei enthält der $ControlBlock$ den “Strong Ref Count” (Starker Referenzzähler), den “Weak Ref Count” (Schwacher Referenzzähler) und einen “Custom Deleter”. Das Problem dabei ist, dass der Overhead von atomaren Anweisungen (wie Cache-Line-Sperren) bedingungslos auftritt, selbst in Situationen, in denen er nur in einem einzigen Thread verwendet wird.

Im Gegensatz dazu trennt Rust Smart Pointer streng nach ihrem Verwendungszweck.

Für Single-Thread: Rc<T> (Reference Counted)
Für Multi-Thread: Arc<T> (Atomic Reference Counted)

$$ Overhead_{Rc} = sizeof(T) + 2 \times sizeof(usize) $$ $$ Overhead_{Arc} = sizeof(T) + 2 \times sizeof(AtomicUsize) $$

In Rust können Sie die Strafe (Penalty) für atomare Operationen vollständig vermeiden (Zero-Cost Abstraction), wenn Sie das für Single-Thread-Anwendungen spezifische Rc<T> verwenden. Und dank des unten beschriebenen Mechanismus zur Threadsicherheit wird das versehentliche Übergeben eines Rc<T> an einen anderen Thread durch das Typsystem vollständig verhindert.

3. Threadsicherheit: Der Schock der “Fearless Concurrency”

Die Multithread-Programmierung in C++ ging schon immer mit der ständigen Angst vor Data Races (Datenwettläufen) und Deadlocks einher.

Mutexe in C++ und die Gefahr der Trennung von Daten

Das C++ std::mutex ist lediglich ein Werkzeug zur exklusiven Steuerung eines “bestimmten Codeblocks (Kritischer Abschnitt)”, und es gibt auf Sprachebene keine Verbindung zwischen den “zu schützenden Daten” und dem “Mutex”.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#include <iostream>
#include <thread>
#include <mutex>
#include <vector>

std::vector<int> shared_data;
std::mutex mtx;

void worker() {
 // Selbst wenn der Entwickler vergisst, die Sperre zu erwerben, wird die Kompilierung normal durchlaufen.
 // std::lock_guard<std::mutex> lock(mtx);
 shared_data.push_back(1); // Fatales Data Race!
}

int main() {
 std::thread t1(worker);
 std::thread t2(worker);
 t1.join();
 t2.join();
 return 0;
}

Rusts Mutex “besitzt” die Daten

In Rust kapselt (besitzt) Mutex<T> den zu schützenden Datentyp T mithilfe von Generics. Um auf die Daten zuzugreifen, ist es zwingend erforderlich, lock() aufzurufen, um ein Guard-Objekt zu erhalten. Es ist syntaktisch unmöglich, die Daten zu berühren, ohne die Sperre (Lock) zu erwerben.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // Die Daten sind vollständig im Mutex gekapselt.
 let shared_data = Arc::new(Mutex::new(Vec::new()));
 let mut handles = vec![];

 for _ in 0..2 {
 // Arc (threadsicherer Referenzzähler) klonen, um ihn zwischen Threads zu teilen.
 let data_clone = Arc::clone(&shared_data);
 let handle = thread::spawn(move || {
 // Ohne den Erwerb des Locks kann auf den internen Vec nicht zugegriffen werden.
 let mut data = data_clone.lock().unwrap();
 data.push(1);
 });
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }
}

Darüber hinaus gibt es in Rust zwei zentrale Traits, die die Sicherheit der Nebenläufigkeit (Concurrency) garantieren.

Send: Typen, deren Eigentümerschaft sicher zwischen Threads übertragen werden kann.
Sync: Typen, die sicher von mehreren Threads gleichzeitig referenziert werden können.

Zum Beispiel implementiert das nicht-threadsichere Rc<T> den Send-Trait nicht. Wenn man also versucht, es an thread::spawn zu übergeben, führt dies sofort zu einem Kompilierungsfehler. Durch diese “Fearless Concurrency (Nebenläufigkeit ohne Furcht)” werden Entwickler von der Angst vor Bugs befreit und können Parallelisierung deutlich aggressiver vorantreiben.

Nach dem Amdahlschen Gesetz (Amdahl’s Law) kann der theoretisch maximale Durchsatz für einen parallelisierbaren Anteil $P$ und einen Parallelitätsgrad $N$ wie folgt ausgedrückt werden:

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

Rust ermöglicht es, Refactorings zur Maximierung dieses $P$-Wertes äußerst sicher durchzuführen, indem man sich voll auf das Typsystem verlässt.

graph TD A["C++ Threadsicherheit"] --> B["Verlässt sich auf das Gedächtnis des Entwicklers"] B --> C["Mutex ist von Daten entkoppelt"] C --> D["Hohes Risiko stiller Data Races"] E["Rust Threadsicherheit"] --> F["Send und Sync Traits"] F --> G["Mutex besitzt die Daten"] G --> H["Data Races zur Kompilierzeit verhindert"]

4. Fehlerbehandlung: Ausnahmen vs. Algebraische Datentypen

Der Standard für die Fehlerbehandlung in C++ sind “Ausnahmen (Exceptions)”. Ausnahmen machen den Kontrollfluss jedoch undurchsichtig und verursachen Performance-Einbußen (Stack Unwinding und Aufblähung der RTTI). In eingebetteten Systemen oder Spiele-Engines werden Ausnahmen oft vollständig deaktiviert (-fno-exceptions), und man entscheidet sich für ein klassisches Design, das Fehlercodes zurückgibt. In C++23 wurde std::expected eingeführt, aber es wird Zeit brauchen, bis es das gesamte Ökosystem durchdringt.

In Rust gibt es das Konzept der Ausnahmen nicht. Fehler werden als reine “Werte” zurückgegeben und durch einen Aufzählungstyp (Algebraischer Datentyp) namens Result<T, E> dargestellt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


use std::fs::File;
use std::io::{self, Read};

// Allein durch den Rückgabetyp wird klar, dass ein IO-Fehler auftreten kann.
fn read_file_content(path: &str) -> Result<String, io::Error> {
 // Der ?-Operator bewirkt eine sofortige vorzeitige Rückgabe (Early Return) bei einem Fehler oder entpackt den Inhalt bei Erfolg.
 let mut file = File::open(path)?;
 let mut content = String::new();
 file.read_to_string(&mut content)?;
 Ok(content)
}

Dieser ?-Operator ist revolutionär. Er eliminiert tiefe Verschachtelungen (die if-Anweisungs-Pyramiden), die bei der Überprüfung von Fehlercodes in C++ auftreten, und bewahrt gleichzeitig einen sauberen Code-Fluss, der dem von Ausnahmen ähnelt, während explizit angegeben wird, bei welchem Funktionsaufruf Fehler propagiert werden.

5. Polymorphismus: Von virtuellen Funktionen und Templates zu Traits

Polymorphismus wird in C++ hauptsächlich durch Klassenvererbung und dynamischen Dispatch über virtuelle Funktionen (virtual) oder statischen Dispatch über Templates (wie CRTP) erreicht.

Beim dynamischen Dispatch wird ein Zeiger (vptr) auf eine Tabelle virtueller Funktionen (vtable) in das Objekt eingebettet, was beim Funktionsaufruf einen Overhead für die Zeigerauflösung verursacht.

$$ T_{dispatch} = T_{lookup\_in\_vtable} + T_{dereference} $$

Rust hat die klassische objektorientierte “Klassenvererbung” verworfen und stattdessen das Konzept der “Traits” eingeführt (ähnlich den Concepts in C++20, aber vielseitiger).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trait Drawable {
 fn draw(&self);
}

struct Circle { radius: f64 }
impl Drawable for Circle {
 fn draw(&self) { println!("Drawing a Circle of radius {}", self.radius); }
}

// Statischer Dispatch (Monomorphisierung / Zero-Overhead)
fn draw_static<T: Drawable>(item: &T) {
 item.draw();
}

// Dynamischer Dispatch (Trait-Objekt)
fn draw_dynamic(item: &dyn Drawable) {
 item.draw();
}

Das Hauptmerkmal des dynamischen Dispatches in Rust (dyn Trait) ist, dass er keinen vptr innerhalb der Datenstruktur hat, sondern einen Fat Pointer verwendet. Ein Fat Pointer hält ein Paar bestehend aus einem “Zeiger auf die Daten” und einem “Zeiger auf die vtable”. Dies macht es extrem einfach, später Traits für Typen zu implementieren (zu erweitern), die in externen Bibliotheken definiert sind, und sie einem dynamischen Dispatch zu unterziehen.

6. Paketverwaltung und Build-Systeme: Die Qualen von CMake und der Segen von Cargo

Eine der größten Schwächen von C++ ist das Fehlen eines Standard-Paketmanagers. Die obskure Syntax von CMakeLists.txt, die Komplexität der Auflösung von Abhängigkeiten mit find_package und die Unterschiede in den Bibliothekspfaden je nach Betriebssystem rauben C++-Entwicklern weiterhin enorm viel Zeit.

Rust ist standardmäßig mit Cargo ausgestattet, einem der weltbesten Paketmanager und Build-Systeme.

graph TD A["C++ Build-Umgebung"] --> B["CMakeLists.txt"] B --> C["vcpkg / Conan Integration"] C --> D["Makefiles / Ninja generieren"] D --> E["Compiler (GCC/Clang/MSVC)"] F["Rust Build-Umgebung"] --> G["Cargo.toml"] G --> H["Abhängigkeiten von crates.io abrufen"] H --> I["rustc (Cargo build)"] I --> J["Ausführfertiges Binary"]

Indem man einfach eine einzige Zeile mit dem Namen und der Version der Abhängigkeitsbibliothek (Crate) zu Cargo.toml hinzufügt, werden die Auflösung transitiver Abhängigkeiten, das Herunterladen und der Build vollautomatisch durchgeführt. Darüber hinaus sind alle für die Entwicklung notwendigen Toolchains, wie Tests (cargo test), Dokumentationsgenerierung (cargo doc), statische Analyse (cargo clippy) und Formatierer (cargo fmt), in diesem einen Befehl integriert. Dieser Komfort hat eine solche Durchschlagskraft, dass man, wenn man ihn einmal erlebt hat, nie wieder zur Build-Umgebung von C++ zurückkehren möchte.

7. Nachteile und die Lernkurve beim Erlernen von Rust

Bisher habe ich über die Vorteile von Rust gesprochen, aber es gibt definitiv “Barrieren” und Nachteile, auf die C++-Entwickler stoßen, wenn sie Rust in der Praxis einsetzen.

1. Der harte Kampf mit dem Borrow Checker

Wenn man versucht, Datenstrukturen, die in C++ “irgendwie mit rohen Zeigern verbunden waren” (z. B. doppelt verkettete Listen, Graphenstrukturen oder selbstreferenzielle Strukturen), unverändert in Rust zu implementieren, wird die Kompilierung aufgrund von Eigentümerschafts- und Lebensdauerbeschränkungen fehlschlagen. Um den Borrow Checker zufriedenzustellen, muss man entweder komplexe Wrapper wie Rc<RefCell<T>> verwenden oder das Design grundlegend überdenken, hin zu Arena-Allokatoren oder indexbasiertem Management.

2. Lange Kompilierungszeiten

Auch C++ wird durch die Verschachtelung von Templates langsam kompiliert, aber die Kompilierungszeit von Rust (insbesondere bei einem Clean Build von Grund auf) ist keineswegs kurz. Da die leistungsstarken Optimierungs-Pässe von LLVM, die Makro-Erweiterung und die Monomorphisierung von Generics zusammenkommen, wird die Build-Zeit in großen Projekten zu einem Engpass. Während der Entwicklung ist es unerlässlich, Workarounds wie die häufige Nutzung von cargo check anzuwenden.

3. Interoperabilität mit C++-Codebasen

Während die Integration mit C (FFI) sehr reibungslos verläuft, ist es äußerst schwierig, bestehende, riesige C++-Codebasen (die Klassen, Templates und virtuelle Funktionen stark nutzen) direkt mit Rust zu verbinden. In den letzten Jahren haben sich Bridge-Tools wie cxx und autocxx weiterentwickelt, aber es gibt immer noch hohe Hürden für eine völlig nahtlose Migration.

Fazit: Sollten wir zu Rust wechseln?

C++ wird auch in Zukunft eine wichtige Rolle in der Entwicklung von Spiele-Engines und in bestehenden riesigen Infrastrukturen spielen. Die Modernisierung durch C++20/23 ist ebenfalls bemerkenswert und ermöglicht ein sichereres Schreiben von Code.

Bei “neu gestarteten Systemprogrammierungsprojekten” fällt es mir jedoch zunehmend schwerer, Gründe zu finden, sich nicht für Rust zu entscheiden. Die “Gewissheit” von Rust – dass man, sobald der Code kompiliert ist, von der Angst vor undefiniertem Verhalten und Speicherbeschädigung befreit ist und Nebenläufigkeit bei hoher Leistung sicher ausführen kann – verbessert das mentale Modell der Entwickler drastisch.

Für einen C++-Entwickler bedeutet das Erlernen von Rust nicht nur das Auswendiglernen einer neuen Syntax, sondern ist eine großartige Erfahrung, um eine neue Perspektive auf “die sichere Verwaltung von Speicher und Threads” zu gewinnen. Ich lade Sie alle ein, den Komfort von Cargo und die Strenge des Borrow Checkers selbst zu erleben.