object-lifetime

I have this code (simplified version): const int& function( const int& param ) { return param; } const int& reference = function( 10 ); //use reference I can't quite decide to which extent C++03 Standard $12.2/5 wording The temporary to which the reference is bound or the temporary that is the complete object to a subobject of which the temporary is bound persists for the lifetime of the reference... is applicable here. Is reference variable in the code above valid or dangling? Will the reference in the calling code prolong the lifetime of the temporary passed as the parameter? Daniel Trebbien

I'm planning to implement a list of Things in C++ where elements might be removed out of order. I don't expect that i'll need any kind of random access (i just need to sweep the list periodically), and the order of items isn't important either. So I thought of std::list<Thing*> with this->position = insert(lst.end(), thing) should do the trick. I'd like the Thing class to remember the position of each instance so that i can later easily do lst.erase(this->position) in constant time. However, i'm still a bit new to C++ STL containers, and i don't know if it's safe to keep iterators for such a

If some function f with parameters p_1 , ..., p_n of types T_1 , ..., T_n respectively is called with arguments a_1 , ..., a_n and its body throws an exception, finishes or returns, in what order are the arguments destroyed and why? Please provide a reference to the standard, if possible. EDIT: I actually wanted to ask about function "parameters", but as T.C. and Columbo managed to clear my confusion, I'm leaving this question be about the arguments and asked a new separate question about the parameters . See the comments on this question for the distinction. R Sahu The order in which the

I was answering a question about the possibility of closures (legitimately) extending object-lifetimes when I ran into some extremely curious code-gen on the part of the C# compiler (4.0 if that matters). The shortest repro I can find is the following: Create a lambda that captures a local while calling a static method of the containing type. Assign the generated delegate-reference to an instance field of the containing object. Result: The compiler creates a closure-object that references the object that created the lambda, when it has no reason to - the 'inner' target of the delegate is a

Consider following sample code: class C { public: int* x; }; void f() { C* c = static_cast<C*>(malloc(sizeof(C))); c->x = nullptr; // <-- here } If I had to live with the uninitialized memory for any reason (of course, if possible, I'd call new C() instead), I still could call the placement constructor. But if I omit this, as above, and initialize every member variable manually, does it result in undefined behaviour? I.e. is circumventing the constructor per se undefined behaviour or is it legal to replace calling it with some equivalent code outside the class? (Came across this via another

I have the following code: std::string getString() { std::string str("hello"); return str; } int main() { const char* cStr = getString().c_str(); std::cout << cStr << std::endl; // this prints garbage } What I thought would happen is that getString() would return a copy of str ( getString() returns by value); thus, the copy of str would stay "alive" in main() until main() returns. This would make cStr point to a valid memory location: the underlying char[] or char* (or whatever) of the copy of str returned by getString() which, remains in main() . However, this is obviously not the case, as

I've encountered somewhat of a problem in MEF's part lifetime which causes memory leaks in my Prism application. My application exports views and viewmodels with the PartCreationPolicy being set to CreationPolicy.NonShared . The views and viewmodels inherit from ViewBase and ViewModelBase respectively, which implements IDisposable . Now, since my parts implement IDisposable , a reference to them is kept by the container, which causes them to not be released by the garbage collector. According to MEF documentation on part lifetime , this is by design: The container will not hold references to