Yes, the lifetime of a local variable is within the scope({,}) in which it is created. Local variables have automatic or local storage. Automatic because they are automatically destroyed once the scope within which they are created ends. However, What you have here is a string literal, which is allocated in an implementation-defined read-only memory. … Read more
The c_str() result becomes invalid if the std::string is destroyed or if a non-const member function of the string is called. So, usually you will want to make a copy of it if you need to keep it around. In the case of your example, it appears that the results of c_str() are used safely, … Read more
You can’t compile this because mutable references are more restrictive than immutable references. A shortened version that illustrates the issue is this: struct MutIntRef<‘a> { r: &’a mut i32 } impl<‘a> MutIntRef<‘a> { fn mut_get(&mut self) -> &’a mut i32 { &mut *self.r } } fn main() { let mut i = 42; let mut … Read more
Neat solution, but each instance of LifetimeManager should use a unique key rather than a constant: private string _key = string.Format(“PerCallContextLifeTimeManager_{0}”, Guid.NewGuid()); Otherwise if you have more than one object registered with PerCallContextLifeTimeManager, they’re sharing the same key to access CallContext, and you won’t get your expected object back. Also worth implementing RemoveValue to ensure … Read more
As far as I understand, you want want the iterator to return a vector of references into itself, right? Unfortunately, it is not possible in Rust. This is the trimmed down Iterator trait: trait Iterator { type Item; fn next(&mut self) -> Option<Item>; } Note that there is no lifetime connection between &mut self and … Read more
The short answer is: no. C++ does not employ garbage collection, like Java or C#. When an object is destroyed, it’s destroyed immediately. Gone for good. Joined the choir invisible. Pining for the fjords, etc… And to say this over a couple of times in different words so that there is no possible weasily reinterpretation… … Read more
There are a two solutions to your problem. Let’s start with the simplest one: Add a lifetime to your trait trait Foo<‘a> { type Item: AsRef<Path>; type Iter: Iterator<Item = Self::Item>; fn get(&’a self) -> Self::Iter; } This requires you to annotate the lifetime everywhere you use the trait. When you implement the trait, you … Read more
There is actually more than one reason why the code above fails. Let’s break it down a little and explore a few options on how to fix it. First let’s remove the new and try building an instance of A directly in main, so that you see that the first part of the problem has … Read more
Check out the entire error: error[E0310]: the parameter type `U` may not live long enough –> src/main.rs:9:24 | 8 | fn add<U: Bar<T>>(&mut self, x: U) { | — help: consider adding an explicit lifetime bound `U: ‘static`… 9 | self.data.push(Box::new(x)); | ^^^^^^^^^^^ | note: …so that the type `U` will meet its required lifetime … Read more
Update 2015-05-16: the code in the original question applied to an old version of Rust, but the concepts remain the same. This answer has been updated to use modern Rust syntax/libraries. (Essentially changing ~[] to Vec and ~str to String and adjusting the code example at the end.) Is my understanding vaguely accurate? […] What … Read more