Rust Systems Programming & Ownership Model Flashcards

Question 1

What are the three core rules of Rust's Ownership Model?

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 (deallocated).

Question 2

What is Rust's Ownership Model?

Accepted Answer

Rust's ownership model is a set of rules checked at compile time that govern how a program manages memory. It ensures memory safety without a garbage collector, preventing common bugs like dangling pointers and data races.

Question 3

Explain "move semantics" in Rust.

Accepted Answer

When a variable holding a heap-allocated value (like `String` or `Vec`) is assigned to another variable or passed to a function, ownership is *moved*. The original variable becomes invalid and cannot be used after the move, preventing double-free errors.
```rust
let s1 = String::from("hello");
let s2 = s1; // s1 is moved to s2, s1 is now invalid
// println!("{}", s1); // Compile-time error!
```

Question 4

What is "borrowing" in Rust?

Accepted Answer

Borrowing allows you to access data without taking ownership. It involves creating references (`&` for immutable, `&mut` for mutable) to a value. References must always be valid and adhere to strict rules enforced by the borrow checker.

Question 5

What are the rules for references (borrowing) in Rust?

Accepted Answer

At any given time, you can have *either* one mutable reference (`&mut T`) *or* any number of immutable references (`&T`) to a particular piece of data. You cannot have both simultaneously. This is known as the "aliasing XOR mutability" rule.

Question 6

What is a "lifetime" in Rust?

Accepted Answer

Lifetimes are a compile-time concept that ensures all references are valid for as long as they are used. They describe the scope for which a reference is valid, preventing dangling references. Rust's borrow checker uses lifetimes to enforce memory safety.

Question 7

When are explicit lifetime annotations (`'a`) required?

Accepted Answer

Explicit lifetime annotations are primarily needed when the Rust compiler cannot infer how the lifetimes of input references relate to the lifetime of an output reference, especially in functions or structs that hold references. This often occurs when a function takes multiple references and returns one of them, or when a struct contains references.

Question 8

Provide an example of explicit lifetime annotation syntax in a function signature.

Accepted Answer

```rust
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}
```
Here, `'a` indicates that both input references `x` and `y` and the returned reference will live for at least the duration of lifetime `'a`.

Question 9

How do you use lifetime annotations in a struct?

Accepted Answer

If a struct holds references, you must annotate the lifetimes for those references to ensure the struct doesn't outlive the data it refers to.
```rust
struct ImportantExcerpt<'a> {
    part: &'a str,
}

// Example usage:
let novel = String::from("Call me Ishmael. Some years ago...");
let first_sentence = novel.split('.').next().expect("Could not find a '.'");
let i = ImportantExcerpt { part: first_sentence };
```

Question 10

What is `Box<T>` used for?

Accepted Answer

`Box` is a smart pointer that allocates values on the heap. It's primarily used for: 1. Storing data on the heap rather than the stack. 2. Enabling recursive data types (e.g., linked lists, trees) where the size isn't known at compile time. 3. Creating trait objects (`Box`) to store values of different types that implement the same trait.

Question 11

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

Accepted Answer

`Rc<T>` (Reference Counting) 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 *single-threaded only* and is used when multiple parts of your program need to own the same data.

Question 12

Explain `Arc` and when it should be used instead of `Rc`.

Accepted Answer

`Arc` (Atomic Reference Counting) is similar to `Rc` but is safe to use across multiple threads. The reference count is updated using atomic operations, ensuring thread safety. Use `Arc` when you need shared ownership of data that will be accessed or modified by multiple threads.

Question 13

What is "interior mutability" in Rust?

Accepted Answer

Interior mutability is a design pattern where you can mutate data even when you have an immutable reference to it. This is typically achieved using types like `RefCell` or `Mutex`, which enforce Rust's borrowing rules at runtime instead of compile time.

Question 14

How does `RefCell<T>` enable interior mutability?

Accepted Answer

`RefCell` allows mutable borrows of its interior value even when `RefCell` itself is immutable. It enforces Rust's borrowing rules *at runtime* via `borrow()` (immutable) and `borrow_mut()` (mutable) methods, which will `panic!` if the rules are violated (e.g., trying to get a mutable borrow while an immutable one is active). It is *single-threaded only*.

Question 15

What is `Option<T>` and how is it used in pattern matching?

Accepted Answer

`Option` is an enum that represents the possibility of a value being present (`Some(T)`) or absent (`None`). It's a fundamental way Rust handles nullable values safely. Pattern matching with `match` or `if let` is used to safely extract the value if `Some`, or handle the `None` case. ```rust let x: Option = Some(5); match x { Some(i) => println!("Value: {}", i), None => println!("No value"), } ```

Question 16

What is `Result<T, E>` and how is it used for error handling?

Accepted Answer

`Result<T, E>` is an enum that represents either success (`Ok(T)`) with a value of type `T`, or failure (`Err(E)`) with an error value of type `E`. It's Rust's primary mechanism for recoverable error handling. Pattern matching (with `match` or `if let`) is used to handle both success and error cases explicitly.

Question 17

Explain the `?` operator for error propagation.

Accepted Answer

The `?` operator is a concise way to propagate `Result` errors. When placed after an expression that returns a `Result`, it will:
1. If the `Result` is `Ok(T)`, unwrap the `T` value and continue.
2. If the `Result` is `Err(E)`, immediately return the `E` value from the current function.
The current function must have a `Result` return type compatible with the error being propagated.

Question 18

When should you use `panic!` versus `Result<T, E>` for error handling?

Accepted Answer

Use `panic!` for unrecoverable errors, bugs, or situations where the program cannot reasonably continue (e.g., out-of-bounds array access due to a logic error). Use `Result<T, E>` for recoverable errors, where the caller might be able to handle the error gracefully (e.g., file not found, network timeout, invalid user input).

Question 19

What are Rust "traits"?

Accepted Answer

Traits are a way to define shared behavior in an abstract way. They are similar to interfaces in other languages. A trait defines a set of methods that a type must implement to satisfy that trait. This enables polymorphism and code reuse.

Question 20

How do you define and implement a basic trait in Rust?

Accepted Answer

```rust
// Define a trait
trait Greet {
    fn greet(&self) -> String;
}

// Implement the trait for a struct
struct Person {
    name: String,
}

impl Greet for Person {
    fn greet(&self) -> String {
        format!("Hello, my name is {}", self.name)
    }
}
```

Question 21

What is a "trait object" (`dyn Trait`) and when is it used?

Accepted Answer

A trait object allows you to work with values of different concrete types that all implement a specific trait, without knowing their exact types at compile time. They enable dynamic dispatch. Trait objects are typically stored in a `Box<dyn Trait>` or `&dyn Trait`. They are used when you need to store a collection of different types that share a common interface.

Question 22

Explain the difference between `unwrap()` and `expect()` for `Option` and `Result`.

Accepted Answer

Both `unwrap()` and `expect()` are methods that extract the inner value from `Some(T)` or `Ok(T)`, or `panic!` if the value is `None` or `Err(E)`.
*   `unwrap()` panics with a generic message.
*   `expect("custom message")` panics with a custom message you provide, making debugging easier by giving context to the panic.
It's generally preferred to use `expect()` over `unwrap()` for better diagnostics.

Rust Systems Programming & Ownership Model

Card Preview

Related Flashcard Sets

ECON201 - Intermediate Microeconomics & Game Theory

NEUR101 - Neurobiology & Action Potentials

French A1/A2 - High-Frequency Vocabulary & Essential Grammar

Kubernetes & Orchestration Essentials (CKA Prep)