ownership-semantics | 易学教程

How does Rust move stack variables that are not Copyable?

阅读更多关于 How does Rust move stack variables that are not Copyable?

问题 There is a great example of Rust's move semantics documented here: Rust Move Semantics on the Rust By Example website. I have a basic understanding of both cases demonstrated. The first being how a primitive can have a new alias and the original can still be used because the end result is a copy seeing as i32 utilizes the Copy trait. This makes good sense to me. Additionally, for many good reasons the second example makes sense in terms of having multiple aliases that refer to an i32 on the

How to manage object life time using Boost library smart pointers?

阅读更多关于 How to manage object life time using Boost library smart pointers?

问题 There is a scenario that i need to solve with shared_ptr and weak_ptr smart pointers. Two threads, thread 1 & 2, are using a shared object called A. Each of the threads have a reference to that object. thread 1 decides to delete object A but at the same time thread 2 might be using it. If i used shared_ptr to hold object A's references in each thread, the object wont get deleted at the right time. What should i do to be able to delete the object when its supposed to and prevent an error in

How to call a method that consumes self on a boxed trait object?

阅读更多关于 How to call a method that consumes self on a boxed trait object?

问题 I have the following sketch of an implementation: trait Listener { fn some_action(&mut self); fn commit(self); } struct FooListener {} impl Listener for FooListener { fn some_action(&mut self) { println!("{:?}", "Action!!"); } fn commit(self) { println!("{:?}", "Commit"); } } struct Transaction { listeners: Vec<Box<Listener>>, } impl Transaction { fn commit(self) { // How would I consume the listeners and call commit() on each of them? } } fn listener() { let transaction = Transaction {

Bad practice to return unique_ptr for raw pointer like ownership semantics?

阅读更多关于 Bad practice to return unique_ptr for raw pointer like ownership semantics?

问题 I've written a static factory method that returns a new Foobar object populated from another data object. I've recently been obsessed with ownership semantics and am wondering if I'm conveying the right message by having this factory method return a unique_ptr . class Foobar { public: static unique_ptr<Foobar> factory(DataObject data); } My intent is to tell client code that they own the pointer. Without a smart pointer, I would simply return Foobar* . I would like, however, to enforce that

What is the difference between dereferencing a raw pointer to a String and a raw pointer to an i32?

阅读更多关于 What is the difference between dereferencing a raw pointer to a String and a raw pointer to an i32?

问题 fn func(s: *mut String, a: *mut i32) -> usize { println!("{}", unsafe { *s }); println!("{}", unsafe { *a }); unsafe { (*s).len() } } fn main() { let mut s = String::from("hello"); let mut a = 10; func(&mut s, &mut a); } The above code fails with the error: error[E0507]: cannot move out of dereference of raw pointer --> src/main.rs:2:29 | 2 | println!("{}", unsafe { *s }); | ^^ cannot move out of dereference of raw pointer Why does it happen for String and not for i32 ? Why is it complaining

When is the storage reclaimed for a resource that is no longer owned?

阅读更多关于 When is the storage reclaimed for a resource that is no longer owned?

问题 There is a vector resource that is allocated in line 2 of the program below. When the program ends, the vector resource is not owned. If a resource is not owned at all, when does it get reclaimed? Is there an explanation using the terminology of Rust ownership semantics and lifetimes that could convince a programmer that this resource is indeed reclaimed? fn main() { let mut v = vec![1,2]; v = vec![3, 4]; } 回答1: when does [an unowned resource] get reclaimed? In Rust terms, an item is dropped

How can I reuse a box that I have moved the value out of?

阅读更多关于 How can I reuse a box that I have moved the value out of?

问题 I have some non-copyable type and a function that consumes and (maybe) produces it: type Foo = Vec<u8>; fn quux(_: Foo) -> Option<Foo> { Some(Vec::new()) } Now consider a type that is somehow conceptually very similar to Box : struct NotBox<T> { contents: T } We can write a function that temporarily moves out contents of the NotBox and puts something back in before returning it: fn bar(mut notbox: NotBox<Foo>) -> Option<NotBox<Foo>> { let foo = notbox.contents; // now `notbox` is "empty"

Conditionally move T out from Rc<T> when the count is 1

阅读更多关于 Conditionally move T out from Rc when the count is 1

问题 Is there a way to move an object from an Rc<T> when the count is 1 ? I am thinking about how one would implement: fn take_ownership<T>(shared: Rc<T>) -> Result<T, Rc<T>> { ... } The semantics would be that you get T if the count is 1 and you get back shared otherwise so you can try again later. 回答1: The standard library provides the Rc::try_unwrap function: fn try_unwrap(this: Rc<T>) -> Result<T, Rc<T>> Returns the contained value, if the Rc has exactly one strong reference. Otherwise, an Err

How can I reuse a box that I have moved the value out of?

阅读更多关于 How can I reuse a box that I have moved the value out of?

I have some non-copyable type and a function that consumes and (maybe) produces it: type Foo = Vec<u8>; fn quux(_: Foo) -> Option<Foo> { Some(Vec::new()) } Now consider a type that is somehow conceptually very similar to Box : struct NotBox<T> { contents: T } We can write a function that temporarily moves out contents of the NotBox and puts something back in before returning it: fn bar(mut notbox: NotBox<Foo>) -> Option<NotBox<Foo>> { let foo = notbox.contents; // now `notbox` is "empty" match quux(foo) { Some(new_foo) => { notbox.contents = new_foo; // we put something back in Some(notbox) }

How does Rust move stack variables that are not Copyable?

阅读更多关于 How does Rust move stack variables that are not Copyable?

There is a great example of Rust's move semantics documented here: Rust Move Semantics on the Rust By Example website. I have a basic understanding of both cases demonstrated. The first being how a primitive can have a new alias and the original can still be used because the end result is a copy seeing as i32 utilizes the Copy trait. This makes good sense to me. Additionally, for many good reasons the second example makes sense in terms of having multiple aliases that refer to an i32 on the heap. Rust enforces ownership rules and therefore the original alias cannot be used now that a new