lifetime

问题 I can run this code fn testf(host: &str) {} fn start(host: &str) { testf(host); testf(host); } but for some reason, I can't run this one: fn testf(host: &str) {} fn start(host: &str) { thread::spawn(move || testf(host)); thread::spawn(move || testf(host)); } because of the following error src/server.rs:30:5: 30:18 error: the type `[closure@src/server.rs:30:19: 30:38 host:&str]` does not fulfill the required lifetime src/server.rs:30 thread::spawn(move || testf(host)); ^~~~~~~~~~~~~ note: type

问题 Assume the following contrived example: struct Board { squares: Vec<i32>, } struct Point<'a> { board: &'a Board, x: i32, y: i32, } impl<'a> Point<'a> { pub fn neighbors(&self) -> impl Iterator<Item = Point<'a>> { [(0, -1), (-1, 0), (1, 0), (1, 0)] .iter().map(|(dx, dy)| Point { board: self.board, x: self.x + dx, y: self.y + dy, }) } } This doesn't compile because from what I understand the lifetime of the points created in the lambda isn't correct: error[E0495]: cannot infer an appropriate

问题 I'd like to make the following code compile: struct Provider {} impl Provider { fn get_string<'a>(&'a self) -> &'a str { "this is a string" } } fn main() { let provider = Provider{}; let mut vec: Vec<&str> = Vec::new(); // PROBLEM: how do I say that this reference s here // needs to live as long as vec? let fun = |s: &str| { vec.push(s); }; fun(provider.get_string()); } Playground link This is the compile error that I get: error[E0495]: cannot infer an appropriate lifetime due to conflicting

问题 I am trying to make this simple code compile: fn dox(x: u8) -> u8 { x*2 } fn main() { let cb: &'static (Fn(u8) -> u8) = &dox; } But it fails with Rust 1.9: x.rs:4:40: 4:43 error: borrowed value does not live long enough x.rs:4 let cb: &'static (Fn(u8) -> u8) = &dox; ^~~ note: reference must be valid for the static lifetime... x.rs:4:44: 5:2 note: ...but borrowed value is only valid for the block suffix following statement 0 at 4:43 x.rs:4 let cb: &'static (Fn(u8) -> u8) = &dox; x.rs:5 } error

问题 I know that calling destructor explicitly can lead to undefined behavior because of double destructor calling, like here: #include <vector> int main() { std::vector<int> foo(10); foo.~vector<int>(); return 0; // Oops, destructor will be called again on return, double-free. } But, what if we call placement new to "resurrect" the object? #include <vector> int main() { std::vector<int> foo(10); foo.~vector<int>(); new (&foo) std::vector<int>(5); return 0; } More formally: What will happen in C++

问题 I thought references only extend the lifetime of temporaries to the lifetime of the reference itself, but the output of the following snippet seems contradictory: #include <iostream> struct X{ ~X(){ std::cout << "Goodbye, cruel world!\n"; } }; X const& f(X const& x = X()){ std::cout << "Inside f()\n"; return x; } void g(X const& x){ std::cout << "Inside g()\n"; } int main(){ g(f()); } Live example. Output: Inside f() Inside g() Goodbye, cruel world! So it seems the temporary is destroyed

问题 How to prevent an activity from being recreated on turning screen off? What I do Start Bejewels and go to the jewelry screen. Press power button shortly. The screen is turned off, but the device is not. Press power button again. What I see The same screen as before turning screen off. In case of my application (trivial one, just a web-app with a single WebView) the scenario is the following: What I do Start my app. The activity onCreate() method loads an URL into the WebView. Press power

问题 I'm having a lot of fun trying to solve the robot simulator Exercism exercise, but I'm facing a value moving problem for which I don't seem to be able to come up with an elegant solution: impl Robot { pub fn new(x: isize, y: isize, d: Direction) -> Self { Robot { position: Coordinate { x: x, y: y }, direction: d } } pub fn turn_right(mut self) -> Self { match self.direction { // ... }; self } pub fn turn_left(mut self) -> Self { match self.direction { // ... }; self } pub fn advance(mut self)

问题 I recently had an error which was simply resolved by changing impl<'a> Foo<'a> { fn foo(&'a self, path: &str) -> Boo<'a> { /* */ } } to impl<'a> Foo<'a> { fn foo(&self, path: &str) -> Boo { /* */ } } which did not make sense according to my understanding, as I thought that the second version is exactly the same as the first with applied lifetime elision. In case we introduce a new lifetime for the method this seems to be the case according this example from the nomicon. fn get_mut(&mut self)

问题 Before I stumbled upon the code below, I was convinced that a lifetime in a type's lifetime parameter would always outlive its own instances. In other words, given a foo: Foo<'a> , then 'a would always outlive foo . Then I was introduced to this counter-argument code by @Luc Danton (Playground): #[derive(Debug)] struct Foo<'a>(std::marker::PhantomData<fn(&'a ())>); fn hint<'a, Arg>(_: &'a Arg) -> Foo<'a> { Foo(std::marker::PhantomData) } fn check<'a>(_: &Foo<'a>, _: &'a ()) {} fn main() { let