Your code should be well-formed, because for temporaries (emphasis mine) Whenever a reference is bound to a temporary or to a subobject thereof, the lifetime of the temporary is extended to match the lifetime of the reference Given A().b[4], b[4] is the subobject of b and the data member b is the subobject of the … Read more
std::initializer_list is not a container, don’t use it to pass values around and expect them to persist DR 1290 changed the wording, you should also be aware of 1565 and 1599 which aren’t ready yet. Then the return value’s array should also survive into the calling function, and it should be possible to preserve it … Read more
A temporary object is destroyed when the full-expression that lexically contains the rvalue whose evaluation created that temporary object is completely evaluated. Let me demonstrate with ASCII art: ____________________ full-expression ranges from ‘b’ to last ‘)’ bar( foo().c_str() ); ^^^^^ ^ | | birth funeral
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 scope of b is the new function, so its memory will be freed when the function returns. But you are trying to return a reference to b from that function. If Rust let you do this, the only code that could possibly use that reference would use it after the value is invalid. The … Read more
I have found nothing in the rust documentation to confirm, but it seems that <‘a: ‘a> is short to qualify the output lifetime of the function (cf lifetime output in the documentation). Here are some tests that seem confirm that : #![allow(unused)] fn f<‘a>() {} fn g<‘a: ‘a>() {} fn h<‘a: ‘a>() -> &’a i32 … Read more
You want a session management strategy that allows your app to function effectively and take advantage of the things that NHibernate gives you – most notably caching and lazy loading. Creating sessions is an inexpensive process and requires little up-front RAM or CPU, so you shouldn’t worry about conserving or re-using sessions (indeed, re-using them … Read more
Er…use new? That’s kind of the point. You can also call the constructor explicitly, but there’s little reason to do it that way Using new/delete normally: A* a = new A(); delete a; Calling the constructor/destructor explicitly (“placement new”): A* a = (A*)malloc(sizeof(A)); new (a) A(); a->~A(); free(a);
The basic thread support in the standard library allows the created threads to outlive the thread that created them; that’s a good thing! However, if you were to pass a reference to a stack-allocated variable to one of these threads, there’s no guarantee that the variable will still be valid by the time the thread … Read more
After staying up way too late, I was able to come up with an example case where the lifetimes matter. Here is the code: static ZERO: i32 = 0; struct Foo<‘a, ‘b> { x: &’a i32, y: &’b i32, } fn get_x_or_zero_ref<‘a, ‘b>(x: &’a i32, y: &’b i32) -> &’a i32 { if *x > … Read more