Rust is a system computer language that focuses on security and performance. Because of its distinctive ownership and borrowing structure, it ensures memory safety without the need for garbage collection. In this article, we’ll go over Rust’s ownership system in detail, replete with code examples, to show how it ensures memory safety.
Understanding Rust Ownership
In Rust, ownership is a fundamental notion used to manage memory. Every value in Rust has a single owner, and when the owner exits scope, the value is immediately deallocated. This removes the need for garbage collection while also protecting memory.
fn main() {
let s1 = String::from("hello");
let s2 = s1; // s1's ownership is moved to s2
// println!(", world!), s1; // This would cause a compile-time error, as s1 no longer owns the value
}
Let’s look at ownership transfer in a function
fn main() {
let s1 = String::from("hello");
takes_ownership(s1); // Ownership of s1 is moved to the function
// println!("{} world!", s1); // This would cause a compile-time error, as s1 no longer owns the value
}
fn takes_ownership(s: String) {
println!("{} world!", s); // s owns the value and can use it
} // s goes out of scope and the value is deallocated
The Three Rules of Ownership
The ownership system in Rust is built on three main rules:
a. In Rust, each value has a singular, distinct owner.
b. A number can be mutable or immutable, but not both at the same time.
c. The value is immediately deallocated when the owner exits the scope.
These principles aid in the prevention of common programming errors like use-after-free, double-free, and data races.
fn main() {
let mut s = String::from("hello");
let r1 = &s; // Immutable borrow
let r2 = &s; // Another immutable borrow is allowed
// let r3 = &mut s; // This would cause a compile-time error because we cannot have a mutable borrow alongside immutable borrows
println!("{} and {}.", r1, r2);
}
Borrowing and References
Borrowing gives you temporary access to a number while keeping ownership of it. In rust, there are two kinds of borrowing:
a. Immutable borrowing: Your code can have read-only access to the same number, preventing data races.
fn main() {
let s = String::from("hello");
let len = calculate_length(&s); // Immutable borrow of s
println!("The length of '{}' is {}.", s, len); // s can still be used because ownership was not transferred
}
fn calculate_length(s: &String) -> usize {
s.len() // s is an immutable reference, so we can read its value
}
b. Mutable borrowing: Each value can only have one mutable reference, preventing data races and guaranteeing exclusive access.
fn main() {
let mut s = String::from("hello");
append_world(&mut s); // Mutable borrow of s
println!("The modified string is: {}", s); // s can still be used because ownership was not transferred
}
fn append_world(s: &mut String) {
s.push_str(" world!"); // s is a mutable reference, so we can modify its value
}
Lifetimes
Lifetimes help the compiler determine how long a reference should be valid, preventing dangling references and preserving memory safety.
Let’s look at explicit lifetimes
fn main() {
let string1 = String::from("abcd"); // Create a new String called string1
let string2 = "xyz"; // Create a string slice called string2
// Call the longest function with string1 and string2 as parameters,
// converting string1 to a string slice using as_str()
let result = longest(string1.as_str(), string2);
// Print the result (the longest string)
println!("The longest string is {}", result);
}
// Define a generic function called longest that takes two string slices with the same lifetime 'a
// The function returns a string slice with the same lifetime 'a
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
// Compare the lengths of the two string slices
if x.len() > y.len() {
x // If x is longer, return x
} else {
y // If y is longer or they have the same length, return y
}
}
We have a lifetime parameter in the longest function definition. This is used to ensure that both input string slices x and y have the same lifetime, denoted by ‘a. The return type of the function has the same lifetime ‘a. This instructs the Rust compiler that the returned reference will be valid for at least as long as the shortest of the input references.
The Rust compiler will infer the appropriate lifetimes for the input references and ensure that the returned reference is valid for that same lifetime when the longest function is called in the main function.
The lifetimes of string1 and string2 in this case are the same as the scope of the main function. Because the longest function returns a reference with the same lifetime as its input references, the returned reference result will have the same lifetime as the main function. This ensures that when we print the result, we are not attempting to access a dangling reference, which protects memory.
let’s look at lifetimes in structs
// Define a struct named Excerpt with a lifetime parameter 'a
struct Excerpt<'a> {
part: &'a str, // The struct contains a field named part with a reference to a str with lifetime 'a
}
fn main() {
let text = String::from("This is a long string."); // Create a new String called text
let first_sentence = &text[0..12]; // Get the first sentence as a string slice
// Create an instance of the Excerpt struct, using the lifetime of first_sentence for the part field
let excerpt = Excerpt { part: first_sentence };
// Print the part field of the excerpt instance
println!("The excerpt is: {}", excerpt.part);
}
In this code, we define an Excerpt struct with the lifetime parameter ‘a. This lifetime parameter is used for the part field, which is a string slice reference. The lifetime parameter ‘a tells the Rust compiler that the reference to the string slice in the part field must be valid for the same amount of time as the lifetime ‘a.
Within the main function, we create a String called text and then extract a string slice from the first sentence, which is saved in the variable first_sentence. The lifespan of first_sentence is linked to that of text.
When we create an instance of the Excerpt struct, we set the part field to first_sentence. Based on the lifetime of first_sentence, the Rust compiler infers the appropriate lifetime for the Excerpt instance. Because first_sentence is derived from text, the lifetime of the Excerpt instance will be the same as the lifetime of the text variable.
The println! statement accesses the Excerpt instance’s part field, which is guaranteed to be valid because the Excerpt instance’s lifetime is linked to the lifetime of text. This prevents us from accessing a dangling reference and maintains memory safety.
Ownership in Practice: A Real-World Example
Consider reading and processing a file’s data. Manual memory management or garbage collection would be needed in other languages to prevent memory leaks. Memory is immediately deallocated by Rust’s ownership system when the owner exits scope.
use std::fs::File; // Import the File struct from the standard library
use std::io::{BufRead, BufReader}; // Import the BufRead trait and BufReader struct from the standard library
fn main() {
let file = File::open("input.txt").expect("Unable to open file"); // Open the file and store its ownership in the `file` variable
let reader = BufReader::new(file); // Create a new BufReader with the ownership of the `file`
// Iterate over the lines of the BufReader
for line in reader.lines() {
let line = line.expect("Unable to read line"); // Get the line and store its ownership in the `line` variable
process_line(&line); // Pass an immutable reference of the `line` to the process_line function (ownership is not transferred)
} // The `reader` and its owned `file` variable go out of scope, and the resources are automatically deallocated
}
fn process_line(line: &str) {
// Process the line
// The ownership of the `line` variable is not transferred to this function, so it will not be deallocated when this function exits
}
In this code snippet, we first open a file and store its ownership in the file variable. We then create a BufReader and pass the ownership of the file to it. The BufReader is responsible for managing the file's resources.
As we iterate over the lines in the BufReader, we read each line and store its ownership in the line variable. We then call the process_line function and pass an immutable reference to the line. This means that the ownership of the line is not transferred to the process_line function, and it will not be deallocated when the function exits.
When the main function completes its execution, the reader and its owned file variable go out of scope. At this point, Rust's ownership system deallocates the resources associated with the file automatically, ensuring that we do not have any memory leaks or resource leaks.
In this case, Rust’s ownership system ensures that resources are correctly managed and deallocated when they exit scope, eliminating the need for manual memory management or garbage collection.
Rust’s ownership system is a novel method of memory management that provides a unique combination of safety and performance. Rust guarantees memory safety without the need for garbage collection by enforcing strict rules on ownership, borrowing, and lifetimes. This not only helps to avoid common programming errors, but it also allows developers to confidently create high-performance and reliable systems. We can see how Rust’s ownership system effectively manages memory allocation and deallocation through the code examples given, allowing developers to concentrate on writing efficient and safe code.
