[cfe-dev] is delete on abstract with non-virtal ever safe?

emmanuel.attia emmanuel.attia at philips.com
Fri Oct 4 02:45:22 PDT 2013


> This has undefined behavior. You're calling a virtual function on an object
whose lifetime has ended (the destructor has already been called).

my_destroy_interface has no destructor so the vtable is not cleared until
the memory is released (since nothing alters it before i get in the operator
delete overload).

Referring to the standards (i'm not sure its the right pdf):
"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."
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf

And that make totally sense since if i add a  (non-virtual) destructor it
still flies, unless the destructor is non trivial (in that case i get as
expected a pure virtual function call).

> This has undefined behavior (you're using 'delete', the static and dynamic
> types don't match, and your base class does not have a virtual
> destructor).

That's the point, i call the overload "my_destroy_interface::operator
delete" and not the global delete operator. Since my_destroy_interface has
no (non trivial) destructor this is the only thing happening when calling
delete on a pointer to my_destroy_interface.

> Nope. See above. Or try giving my_destroy_interface a user-declared
> (non-virtual) destructor, and watch as it either gets called twice or your
> program starts to die due to a pure virtual function call (depending on
> implementation details).

Giving to my_destructor_interface a virtual destructor would make it called
twice as you said, thats why it's not there in this construct (and it makes
sense since its an interface).




--
View this message in context: http://clang-developers.42468.n3.nabble.com/is-delete-on-abstract-with-non-virtal-ever-safe-tp4025653p4034880.html
Sent from the Clang Developers mailing list archive at Nabble.com.




More information about the cfe-dev mailing list