Is gcc allowed to eliminate writes in a destructor?

Norbert Lange lange@chello.at
Wed Jun 10 08:09:00 GMT 2015


@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@gmail.com>:
> 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.



More information about the Gcc-help mailing list