@Avi: Not everything thats common is valid. Could give you a list what people who primarly use msvc call valid and "normal" code @Jonathan: Thanks, I couldnt figure this out from the standard, it wording would assume that foo is called with a pointer to an object whose lifetime ended. If I understand this correctly, assume I got two classes,Base -> Derived and Base has a virtual destr. and a (non-pure) function called cleanup, overridden in Derived and accessing members not in Base. After construction the object will somewhat look like this: &VTableDerived [members of Derived] &VTableBaseD (with Derived::cleanup) [members of Base] After ~Derived() was running, the Object will look like this: # &VTableDerived (undefined?) # [members of Derived] (undefined?) &VTableBaseB (with Base::cleanup) [members of Base] So the vtable of Base gets altered after ~Derived() finished and Base::cleanup will be called? Regards, Norbert 2015-06-10 9:39 GMT+02:00 Jonathan Wakely <jwakely.gcc@xxxxxxxxx>: > On 10 June 2015 at 08:16, Norbert Lange wrote: >> But I`d be interested what should/could happen if derived destructors >> already did their work, and foo tries to use RTTI (dynamic_cast, >> typeid). I suspect this is undefined behaviour anyway given that these >> could throw, > > That's not undefined behaviour, just ill-advised. > > Since C++11 destructors are implicitly noexcept(true) by default, so > if a destructor exits via an exception the runtime will call > std::terminate(). That's perfectly well defined. > >> and similarly dangerous as accessing virtual functions >> that might have overrides in the derived classes. > > Nothing undefined there either, the dynamic type of the object is > CMyClass after the derived destructor runs, so as long as it isn't > pure virtual you can call the function, but it won't dispatch to the > derived override.
