lifetime

问题 fn main() { let mut x: Vec<&i32> = vec![]; let a = 1; x.push(&a); drop(x); // x.len(); // error[E0382]: use of moved value: `x` } // `a` dropped here while still borrowed The compiler knows drop() drops x (as evident from the error in the commented-out code) but still thinks the variable is borrowing from a ! This is unfair! Should this be considered as one of numerous dupes of rust-lang/rust#6393 (which is now tracked by rust-lang/rfcs#811?) But the discussion there seems to be centered on

问题 Consider this code: const char* someFun() { // ... some stuff return \"Some text!!\" } int main() { { // Block: A const char* retStr = someFun(); // use retStr } } In the function someFun() , where is \"Some text!!\" stored (I think it may be in some static area of ROM) and what is its scope lifetime? Will the memory pointed by retStr be occupied throughout the program or be released once the block A exits? 回答1: The C++ Standard does not say where string literals should be stored. It does

问题 When I run the following code,it works fine for C: #include<stdio.h> int main(void) { const int x=5; char arr[x]; printf(\"%d\",sizeof(arr)); } But not only had I read before that const qualified variables are not real constants (that\'s why they can\'t be used in case condition of switch-case ),but the following link from IBM corroborates that (IBMLINK) and says: const int k = 10; int ary[k]; /* allowed in C++, not legal in C */ Why then am I allowed to use a const qualified variable in C as

问题 I\'m using serde and serde_json 1.0 to decode data from a base64 string: fn from_base64_str<T: Deserialize>(string: &str) -> T { let slice = decode_config(string, URL_SAFE).unwrap(); serde_json::from_slice(&slice).unwrap() } When I compile, I got this: error[E0106]: missing lifetime specifier --> src/main.rs:6:23 | 6 | fn from_base64_str<T: Deserialize>(string: &str) -> T { | ^^^^^^^^^^^ expected lifetime parameter Checking the serde doc, Deserialize is defined as: pub trait Deserialize<\'de>

问题 In Rust, when we want a struct to contain references, we typically define their lifetimes as such: struct Foo<\'a> { x: &\'a i32, y: &\'a i32, } But it\'s also possible to define multiple lifetimes for different references in the same struct: struct Foo<\'a, \'b> { x: &\'a i32, y: &\'b i32, } When is it ever useful to do this? Can someone provide some example code that doesn\'t compile when both lifetimes are \'a but does compile when the lifetimes are \'a and \'b (or vice versa)? 回答1: After

问题 I have a trait Matrix and generic function semi_def<T: Matrix>(x: &T) that I would like to operate on that trait. The function requires an operator trait, say Mul , be implemented on T . However, I can\'t seem to make the lifetimes happy if one of the references is to a local variable. How do I write the lifetimes for references in the type constraint when one of them is just a local temporary reference? use std::ops::Mul; trait Matrix: Clone { fn transpose(self) -> Self; } #[derive(Clone)]

问题 How to set session lifetime in PHP? I Want to set it to forever as long as the request is exist. The request is AJAX. My PHP code that handle AJAX request is: // AJAX.php <?php session_start(); $_SESSION[\'counter\'] = $_SESSION[\'counter\'] + 1; header(\'Content-type: application/json\'); echo json_encode(array(\'tick\' => $_SESSION[\'counter\'])); ?> and the JavaScript: $(document).ready(function() { function check() { getJSON(\'ajax.php\'); } function getJSON(url) { return $.getJSON( url,

问题 I\'m having lifetime issues with a particular function in my code. I\'m following a tutorial in an attempt to learn Rust and SDL. The tutorial was slightly older and the SDL library has changed since its been written, so I\'m following along while also adapting it towards the latest version of Rust-SDL. The lifetime problem is in this function: pub fn ttf_str_sprite(&mut self, text: &str, font_path: &\'static str, size: i32, color: Color) -> Option<Sprite> { if let Some(font) = self.cached

问题 I have created a data structure in Rust and I want to create iterators for it. Immutable iterators are easy enough. I currently have this, and it works fine: // This is a mock of the \"real\" EdgeIndexes class as // the one in my real program is somewhat complex, but // of identical type struct EdgeIndexes; impl Iterator for EdgeIndexes { type Item = usize; fn next(&mut self) -> Option<Self::Item> { Some(0) } fn size_hint(&self) -> (usize, Option<usize>) { (0, None) } } pub struct CGraph<E> {

问题 I was reading the lifetimes chapter of the Rust book, and I came across this example for a named/explicit lifetime: struct Foo<\'a> { x: &\'a i32, } fn main() { let x; // -+ x goes into scope // | { // | let y = &5; // ---+ y goes into scope let f = Foo { x: y }; // ---+ f goes into scope x = &f.x; // | | error here } // ---+ f and y go out of scope // | println!(\"{}\", x); // | } // -+ x goes out of scope It\'s quite clear to me that the error being prevented by the compiler is the use