Rust Programming - Ownership, Borrowing & Systems Concurrency Flashcards

Question 1

What is Ownership in Rust?

Accepted Answer

Ownership is Rust's core memory management system, ensuring memory safety without a garbage collector. Each value has a single *owner*, and when the owner goes out of scope, the value is dropped, freeing its resources.

Question 2

What are the three main Ownership Rules in Rust?

Accepted Answer

1. Each value in Rust has a variable that's called its *owner*.
2. There can only be one owner at a time.
3. When the owner goes out of scope, the value will be dropped.

Question 3

Explain "Move Semantics" in Rust.

Accepted Answer

For types that don't implement the `Copy` trait (e.g., `String`, `Vec<T>`), assigning a variable to another or passing it to a function *moves* ownership. The original variable becomes invalid, preventing double-free errors and ensuring memory safety. This is a shallow copy followed by invalidation of the original.

Question 4

Provide an example of a "move" in Rust.

Accepted Answer

```rust
let s1 = String::from("hello");
let s2 = s1; // s1 is moved to s2. s1 is now invalid.
// println!("{}", s1); // This would cause a compile-time error!
println!("{}", s2); // This is valid.
```

Question 5

When does Rust perform a "copy" instead of a "move"?

Accepted Answer

For types that implement the `Copy` trait (e.g., integers, booleans, characters, fixed-size arrays, tuples containing only `Copy` types), assignment or passing to a function performs a *copy*. Both variables remain valid. These types are typically stored entirely on the stack.

Question 6

What happens when an owner variable goes out of scope?

Accepted Answer

When an owner variable goes out of scope, Rust automatically calls the `drop` function on the owned data. This frees the associated memory and resources, preventing memory leaks and ensuring proper cleanup.

Question 7

What is "Borrowing" in Rust?

Accepted Answer

Borrowing allows you to access data owned by another variable without taking ownership. This is done by creating *references* (`&`) to the data. References are like pointers but are guaranteed to be valid by the borrow checker, preventing null or dangling pointers.

Question 8

Differentiate between immutable and mutable references.

Accepted Answer

*   **Immutable Reference (`&T`)**: Allows reading the data but not modifying it. You can have multiple immutable references to the same data simultaneously.
*   **Mutable Reference (`&mut T`)**: Allows reading and modifying the data. You can only have *one* mutable reference to a particular piece of data in a given scope.

Question 9

Explain the core rules of the Rust Borrow Checker.

Accepted Answer

The Borrow Checker enforces two main rules at compile time to prevent data races and dangling references:
1.  You can have *one mutable reference* to a particular piece of data.
2.  OR you can have *any number of immutable references* to that data.
You cannot have both mutable and immutable references to the same data simultaneously in the same scope.

Question 10

How does Rust prevent "dangling references"?

Accepted Answer

Rust's borrow checker ensures that references always point to valid data. It checks that the data a reference points to lives at least as long as the reference itself. If a reference would outlive its data, it's a compile-time error, preventing runtime crashes.

Question 11

What are "Lifetimes" in Rust?

Accepted Answer

Lifetimes are a compile-time concept that describe the scope for which a reference is valid. They ensure that references never outlive the data they point to, preventing dangling references. They are usually inferred by the compiler but sometimes need explicit annotation.

Question 12

When are explicit lifetime specifiers (e.g., `'a`) necessary?

Accepted Answer

Explicit lifetime specifiers are needed when the compiler cannot unambiguously determine the relationship between the lifetimes of multiple references, especially in function signatures or struct definitions, to ensure memory safety. They help the borrow checker understand how long references should be valid.

Question 13

How are lifetimes used in struct definitions?

Accepted Answer

If a struct holds references, you must annotate those references with lifetime parameters to indicate that the struct cannot outlive the data it refers to. This ensures the references within the struct remain valid.
```rust
struct ImportantExcerpt<'a> {
    part: &'a str,
}
```

Question 14

How are lifetimes used in function signatures?

Accepted Answer

When a function takes multiple references and returns a reference, explicit lifetime annotations may be needed to tell the compiler which input reference's lifetime the output reference's lifetime is tied to. This clarifies the borrow checker's work.
```rust
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}
```

Question 15

What is the `'static` lifetime?

Accepted Answer

The `'static` lifetime denotes that a reference can live for the entire duration of the program. This is typically used for string literals (`&'static str`), global constants, or data embedded directly into the program's binary, as they are available for the entire runtime.

Question 16

What are "Smart Pointers" in Rust?

Accepted Answer

Smart pointers are data structures that act like pointers but also have additional metadata and capabilities. They own data and often manage memory or resources, providing features like reference counting, interior mutability, or custom cleanup logic beyond basic references.

Question 17

Explain `Box<T>` and its primary use case.

Accepted Answer

`Box` is a smart pointer that allocates data on the heap. It's primarily used for: 1. Storing data on the heap when its size is unknown at compile time (e.g., recursive data structures). 2. Transferring ownership of large amounts of data without copying. 3. When you need to own a trait object (e.g., `Box`).

Question 18

Explain `Rc<T>` and its primary use case.

Accepted Answer

`Rc<T>` (Reference Counted) is a smart pointer that enables multiple ownership of data on the heap. It keeps track of the number of references to a value, and the value is dropped only when the reference count reaches zero. It is *not* thread-safe and should only be used in single-threaded scenarios.

Question 19

Explain `Arc<T>` and its primary use case.

Accepted Answer

`Arc` (Atomic Reference Counted) is a thread-safe version of `Rc`. It allows multiple threads to share ownership of data on the heap. The reference count is updated atomically, making it safe for concurrent access. It's crucial for sharing data between threads where multiple ownership is required.

Question 20

How does Rust achieve "Fearless Concurrency"?

Accepted Answer

Rust's ownership and borrowing system, combined with its type system (especially the `Send` and `Sync` traits), prevents common concurrency bugs like data races at compile time. This allows developers to write concurrent code with confidence, as the compiler enforces safety guarantees.

Question 21

Explain `Mutex<T>` and its role in concurrency.

Accepted Answer

`Mutex` (Mutual Exclusion) is a smart pointer that provides exclusive access to data. It allows only one thread at a time to access the inner data, preventing data races when multiple threads try to modify shared mutable state. It's often used with `Arc` for shared ownership across threads, ensuring safe mutation.

Question 22

What are `Option` and `Result` used for in Rust?

Accepted Answer

* `Option`: An enum representing the presence (`Some(T)`) or absence (`None`) of a value. Used for nullable values or when a function might not return a value, forcing explicit handling of both cases. * `Result`: An enum representing either success (`Ok(T)`) with a value `T` or failure (`Err(E)`) with an error `E`. Used for fallible operations where an error might occur, promoting robust error handling.

Question 23

How is pattern matching used with `Option` and `Result`?

Accepted Answer

The `match` expression is commonly used to handle the different variants of `Option` and `Result`. This forces the programmer to explicitly consider both the success/presence and failure/absence cases, making error handling and null checks robust and explicit.
```rust
match some_option {
    Some(value) => println!("Got: {}", value),
    None => println!("No value"),
}
```

Rust Programming - Ownership, Borrowing & Systems Concurrency

Cards in this deck

Related Flashcard Sets

Rust Systems Programming & Ownership Model

JLPT N5 - Essential Grammar & Kanji

Kubernetes Fundamentals & Container Orchestration

Pharmacology - Drug Classes & Mechanisms of Action