Rust memory management: Difference between revisions
Line 105: | Line 105: | ||
<blockquote> | <blockquote> | ||
Lifetimes prevent dangling references.<br> | Lifetimes prevent dangling references.<br> | ||
If you return a reference to an object created within an inner scope,<br> | If you return a reference to an object created within an inner scope (on the stack?),<br> | ||
that object would normally be dropped when it's scope ends. | that object would normally be dropped when it's scope ends. | ||
Revision as of 22:51, 8 February 2023
Rust uses ownership semantics for memory management.
Documentation
ownership tut docs https://doc.rust-lang.org/stable/book/ch04-00-understanding-ownership.html lifetime tut docs https://doc.rust-lang.org/stable/book/ch10-03-lifetime-syntax.html
General
Stack
The stack is
- a LIFO
- push=add, pop=remove (from the top)
- only supports fixed-size datatypes
- fast
Heap
- access provided through pointers (a fixed-size, usable on stack)
- slower
Ownership
Copy Trait
- Objects have a single owner at once
- When owner goes out of scope, value is dropped (with
drop()
)- When an object is passed as a function-parameter, that function now owns it (and it cannot be referenced in current context).
See example of ownership in action.
fn print_i32(i: i32) { println!("{}", i); } fn print_str(s: String) { println!("{}", s); } fn main() { let i = 123; print_i32(i); // `i` has `Copy` trait, `foo` gets a shallow copy println!("{}", i); // valid! `i` is still owned by `main()` let s = String::from("abc"); print_str(s); // `s` does not have `Copy` trait, pointer passed to function, which now owns it println!("{}", s); // <-- BANG! not allowed to use `s` anymore }References
Passing references enables passing objects to arguments without transferring ownership.
However:
- only a single mutable reference can exist for the same object at a time.
- if a mutable reference for an object exists, there cannot be immutable references to that object
I'm thinking of this as a read/write lock (multiple readers allowed, nobody can read/write while writing).
fn print_str(s: &String) { println!("{}", s); } fn main() { let s = String::from("abc"); print_str(&s); println!("{}", s); // <<-- valid! `main` still owns the object }In rust, because of lifetime semantics, you can't return a reference from an object created in a function.
You need to return the object itself, so that it's ownership is transferred.// INVALID! fn foo() -> &String { let s = String::from("hi"); &s } // VALID fn foo() -> String { let s = String::from("hi"); s }Lifetimes
Syntax
fn foo<'a>(i: &str) -> &str {} // reference fn foo<'a>(i: &'a str) -> &'a str {} // reference, w/ lifetime 'a fn foo<'a>(i: &'a mut str) -> &'a str {} // mutable reference, w/ lifetime 'aWhy/When?
Lifetimes prevent dangling references.
If you return a reference to an object created within an inner scope (on the stack?),
that object would normally be dropped when it's scope ends.from rust book
{ // --+ outer_scope let r; // | { // | -+ inner_scope let x = 5; // | | r = &x; // | | } // | -+ } // --+You can instead attach a lifetime to it, that effectively says:
don't drop this object, until this other object is dropped.
Here's a real example:use rand::Rng; // tell the compiler not to drop the returned reference // until the earliest dropping of either params `a` or `b`. // fn choose_random<'a>(a: &'a str, b: &'a str) -> &'a str { let list = vec![a, b]; let i = rand::thread_rng().gen_range(0..=1); list[i] } let val = choose_random("abc", "def"); println!("{}", val);