Box, Rc and owned resource cleanup

Sometimes a record needs an owned allocation or several readers need to keep the same record alive. Box owns a heap allocation. Rc provides reference-counted shared ownership within one thread. They solve different ownership needs rather than replacing every ordinary value or reference.

Cloning an Rc increases its strong owner count without cloning the underlying record. The allocation is released when the last strong owner is dropped. Drop defines cleanup when a value is destroyed; Rust inserts that cleanup according to ownership and scope. Arc is the thread-safe reference-counted alternative, but does not make all inner operations thread-safe.

Save the complete source as main.rs in the Rust environment. No standard input is needed.

Rust 2024 · complete program

use std::rc::Rc;
fn main() {
  let mark = Box::new(80);
  println!("Boxed mark: {mark}");
  let name = Rc::new(String::from("Diya"));
  let reader = Rc::clone(&name);
  println!("Owners: {}", Rc::strong_count(&name));
  drop(reader);
  println!("Owners: {}", Rc::strong_count(&name));
}

Expected output

Boxed mark: 80
Owners: 2
Owners: 1

Follow the execution

The Box owns its allocated integer. Both name and reader then own references to the same String allocation, giving a count of two. Explicitly dropping reader decreases the count to one. Dropping the last owner later frees the allocation.

Try the complete program in the Rust compiler. For tests, Cargo commands and local files, use the specified local environment.

Your task: Does Rc::clone create an independent editable copy of the student name?

Rust 2024 · complete program

use std::rc::Rc;
fn main() {
  let mark = Box::new(80);
  println!("Boxed mark: {mark}");
  let name = Rc::new(String::from("Diya"));
  let reader = Rc::clone(&name);
  println!("Owners: {}", Rc::strong_count(&name));
  drop(reader);
  println!("Owners: {}", Rc::strong_count(&name));
}

Worked answer

No. It adds another owner of the same allocation. Clone behavior must be interpreted through the type being cloned.

Strong reference cycles can prevent reference-counted cleanup; Weak references can break ownership cycles. RefCell offers runtime-checked interior borrowing for appropriate single-threaded designs, while Mutex protects shared access across threads. Neither is a reason to ignore ownership reasoning.

API details: official Rust documentation for this boundary.

No. It adds another owner of the same allocation. Clone behavior must be interpreted through the type being cloned. Strong reference cycles can prevent reference-counted cleanup; Weak references can break ownership cycles.

Further reading: the official Rust Book on box, rc and owned resource cleanup.