Informatik Programmierung – Rust Ownership und Borrowing
Karteikarten zum Thema „Informatik“ · 15 Karten · von atrio. Beispiele: Was sind die drei Regeln des Ownership in Rust? · Was passiert bei einer Zuweisung vo…
Karten
15 KartenWas sind die drei Regeln des Ownership in Rust?
Rückseite
Jeder Wert hat genau einen Owner. Der Owner bestimmt die Lebensdauer. Wenn der Owner den Scope verlässt, wird der Wert gedroppt.
Was passiert bei einer Zuweisung von nicht-Copy-Typen in Rust?
Rückseite
Ein Move erfolgt: Der neue Owner übernimmt die Verantwortung, der alte Owner wird ungültig und kann nicht mehr genutzt werden.
Welche Typen implementieren das Copy-Trait und werden nicht gemoved?
Rückseite
Primitive Typen wie Integer, Float, Boolean, Char, Tupel aus Copy-Typen sowie Funktionszeiger – sie sind trivial kopierbar auf dem Stack.
Was ist der Unterschied zwischen einer immutablen und einer mutablen Referenz?
Rückseite
Immutable Referenz (&T) erlaubt nur Lesen. Mutable Referenz (&mut T) erlaubt Lesen und Schreiben, aber exklusiv – keine anderen Referenzen dürfen gleichzeitig existieren.
Welche Regel gilt für gleichzeitiges Borrowing in Rust?
Rückseite
Entweder beliebig viele immutable Referenzen ODER genau eine mutable Referenz zur selben Zeit – nie beides gemischt, verhindert Data Races.
Wie verhindert Rust hängende Referenzen (Dangling References)?
Rückseite
Der Borrow-Checker prüft, dass Referenzen nicht länger leben als ihre Owner. Lebenszeiten (Lifetimes) werden statisch verifiziert.
Was drückt ein Lifetime-Parameter wie 'a in Funktionssignaturen aus?
Rückseite
Die Referenzen leben mindestens so lange wie 'a. Der Compiler prüft, dass Aufrufer Referenzen mit ausreichender Lebensdauer übergibt.
Wann ist der 'static Lifetime erforderlich oder nützlich?
Rückseite
Bei String-Literalen, globalen Konstanten oder wenn Daten für die gesamte Programmlaufzeit gültig sein müssen – oft als Standard für trait bounds.
Wie verhält sich Ownership bei Struct-Feldern ohne Lifetime-Annotation?
Rückseite
Der Struct übernimmt Ownership seiner Felder. Bei Referenzen in Structs sind Lifetime-Parameter Pflicht, damit der Compiler die Gültigkeit prüfen kann.
Wann nutzt man Box<T>, Rc<T> oder Arc<T> statt direkter Ownership?
Rückseite
Box für Heap-Allokation mit single Owner, Rc für shared Ownership (single-threaded), Arc für thread-sicheres shared Ownership via Atomic Reference Counting.
Was ermöglicht Interior Mutability durch RefCell<T>?
Rückseite
Laufzeit-Prüfung der Borrowing-Regeln: immutable Zugriff nach außen, aber mutable Borrows zur Laufzeit erlaubt – nützlich für Cache, Mock-Objekte, Graphen.
Welcher Fehler tritt auf, wenn man eine mutable Referenz nach einer immutablen nutzt?
Rückseite
Compile-Fehler: 'cannot borrow as mutable because it is also borrowed as immutable' – der Borrow-Checker verbietet überlappende mutable/immutable Borrows.
Wie löst man den 'use of moved value' Fehler bei Closures?
Rückseite
Move-Keyword vor der Closure erzwingt Ownership-Übergabe, oder Clone/Reference-Counting (Rc/Arc) für shared Ownership bei Captures.
Was bewirkt der 'drop' Trait und wann wird er aufgerufen?
Rückseite
Definiert Bereinigungslogik beim Scope-Ende. Wird automatisch aufgerufen, wenn Owner den Scope verlässt – RAII-Muster für Ressourcenmanagement.
Wie funktioniert Reborrowing bei nested mutable References?
Rückseite
Eine mutable Referenz kann temporär reborrowed werden (&mut *ref). Das Original ist währenddessen 'eingefroren' und nach Reborrow-Ende wieder nutzbar.