There are times when Rust's insistence that each data value has only one owner just doesn't fit our program's data model. What if we're writing a word processing engine, and we wanted people to be able to include the same image in multiple places without wasting memory on duplicates; or what if we were modeling an organization where one person might be referenced by multiple roles?
We could have one definitive owner of the shared information, and use borrows everywhere else, and if that works, it's probably the way to go. There are two situations where it doesn't work, though:
- We don't know how long the lifetimes of each of the users of the shared data value will be
- We need write access to the shared data in at least one of the users
A word processing engine is a good example of problem number one: An image may be used more than once in the same document, but we never know when the user might decide to delete one of them, nor do we know which one will be deleted. Maybe all of them will be deleted, and who knows what order that will happen in or what the timing will be like.
To fully address problem number two, we'll need both the Rc and RefCell data types, so we'll talk about that later in this chapter.
When we find ourselves in a situation where we need to share information without knowing about the relative lifetimes of the various borrows of that information, we can use the Rc smart pointer to make everything work. Rc stands for "reference counted," and what it does is keep track of how many copies of itself exist. When that number reaches zero, the lifetime of the contained data value ends.
Let's look at creating some reference-counted smart pointers:
pub fn make_vector_of_rcs() -> Vec<Rc<String>> {
let ada = Rc::new("Ada".to_string());
let mel = Rc::new("Mel".to_string());
return vec![
Rc::clone(&ada),
Rc::clone(&mel),
Rc::clone(&ada),
Rc::clone(&ada),
Rc::clone(&mel),
Rc::clone(&ada),
Rc::clone(&mel),
];
}
We created the first Rc values using Rc::new, on the first two lines of the function body. Both of them contain a String value.
After that, we used Rc::clone to create several duplicates of each Rc. Keep in mind that the String values are not being duplicated, just the Rc smart pointer. The returned vector contains four Rcs that share access to the same ada string, and three that share access to the same mel string.
Then the function's scope ends, and so does the lifetime of the original ada and mel reference-counted smart pointers. However, the various copies are part of the return value, so their lifetimes do not end, and as a consequence the reference counts of the two string values are still greater than zero, and their lifetimes also do not end.
Now we'll write a short program that relies on user input to determine when the lifetime of each of the Rc copies ends. There's no fixed order in which the Rcs are to be removed, so the compiler can't know ahead of time when it's safe to clean up their shared data values, but thanks to the reference counting mechanism, the String values are retained as long as they are needed, and then their lifetime ends.
Here, we remove elements from the vector based on the user input:
let mut ada_and_mel = make_vector_of_rcs();
while ada_and_mel.len() > 0 {
println!("{:?}", ada_and_mel);
print!("Remove which: ");
io::stdout().flush().unwrap();
let mut line = String::new();
io::stdin().read_line(&mut line).unwrap();
let idx: usize = line.trim().parse().unwrap();
ada_and_mel.remove(idx);
}
First, we call our make_vector_of_rcs function to create the initial vector of reference-counted smart pointers to the shared data.
Then, we loop as long as there are any values still stored in the vector. Within the loop, we first print out the current vector (the {:?} code tells Rust to print out the 'debug' representation of the vector, which looks like a Rust array expression). Then we print out a prompt, and flush the output stream to make sure the prompt is actually displayed. Then we read a line from the input stream, parse it into an integer, and use that integer as an index to remove an element from the vector.
When we run that program, it looks like this:
When the last Rc that references the "Mel" value is removed, the lifetime of that String finally ends, and the same goes for the String containing "Ada".