object-lifetime

class A { public event EventHandler AEvent; } class B { private A _foo; private int _bar; public void AttachToAEvent() { _foo.AEvent += delegate() { ... UseBar(_bar); ... } } } Since delegate captures variable this._bar , does it implicitly hold to the instance of B ? Will instance of B be referenced through the event handler and captured variable by an instance of A ? Would it be different if _bar was a local variable of the AttachToAEvent method? Since in my case an instance of A lives far longer and is far smaller than an instance of B , I'm worried to cause a "memory leak" by doing this.

It seems like a silly question, but is the exact moment at which return xxx; is "executed" in a function unambiguously defined? Please see the following example to see what I mean ( here live ): #include <iostream> #include <string> #include <utility> //changes the value of the underlying buffer //when destructed class Writer{ public: std::string &s; Writer(std::string &s_):s(s_){} ~Writer(){ s+="B"; } }; std::string make_string_ok(){ std::string res("A"); Writer w(res); return res; } int main() { std::cout<<make_string_ok()<<std::endl; } What I naively expect to happen, while make_string_ok

Which code of these has UB (specifically, which violates strict aliasing rule)? void a() { std::vector<char> v(sizeof(float)); float *f = reinterpret_cast<float *>(v.data()); *f = 42; } void b() { char *a = new char[sizeof(float)]; float *f = reinterpret_cast<float *>(a); *f = 42; } void c() { char *a = new char[sizeof(float)]; float *f = new(a) float; *f = 42; } void d() { char *a = (char*)malloc(sizeof(float)); float *f = reinterpret_cast<float *>(a); *f = 42; } void e() { char *a = (char*)operator new(sizeof(float)); float *f = reinterpret_cast<float *>(a); *f = 42; } I ask this, because of

[class.dtor]/15 reads, emphasis mine: Once a destructor is invoked for an object, the object no longer exists ; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended (3.8). However, as far as I can tell, this is the only reference in the standard to an object "existing." This also seems to contrast with [basic.life], which is more specific: The lifetime of an object of type T ends when: if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or the storage which the object occupies is reused or released. We have two

I have below mentioned function in C++/MFC: CString StringFunc() { std::string abc = "Hello"; return abc.c_str(); } int main() { CString Temp = StringFunc(); Use_Temp(Temp); } 1.) What would be the lifetime of abc.c_str() pointer returned by StringFunc(), would it be safely copied to variable 'Temp' after StringFunc() returns ? 2.) CString Temp = StringFunc() is a Shallow copy operation or Deep Copying ? What would be the lifetime of abc.c_str() pointer returned by StringFunc(), would it be safely copied to variable 'Temp' after StringFunc() returns ? abc will be valid until StringFunc()

Is the following code legal in C++? template<typename T> class Foo { public: Foo(T& v) : v_(v) {} private: T& v_; }; int a = 10; Foo<int> f(a); void Bar(int& a) { new (&f)Foo<int>(a); } References are not supposed to be bound twice, right? This is perfectly invalid. [basic.life]/1, emphasis mine: The lifetime of an object of type T ends when: if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or the storage which the object occupies is reused or released. The placement new reuses the storage, ending the lifetime of the object denoted by f . [basic.life]/7:

I have a .NET C# / C++ app which uses a call to exit(0) (from <stdlib.h> ) in a thread in order to terminate. The strange part is, under some circumstances, the finalizers of the managed objects are called right after the call to exit , and in other circumstances, they are not called at all. The circumstances are pretty deterministic - the app calls some methods from an external plugin dll (written in unmanaged C) during its lifetime. If I use dll A, the finalizers are always called. If I use dll B, the finalizers are never called. What's the expected behaviour of finalizers in case of an exit