[ub] Non-virtual destructor call

Sebastian Redl sebastian.redl at getdesigned.at
Fri Dec 13 14:17:47 CET 2013


On 2013-12-13 13:56, Andrzej Krzemienski wrote:
>
> There is no harm, except that this is defined as UB. Could the rule be 
> relaxed to say that if the derived type is layout-compatible with the 
> base class and its destructor is implicitly declared or explicitly 
> defaulted, the behaviur is well defined?

This would turn a rather simple rule (if the destructor is not virtual 
and you delete through a base class pointer it's UB) into a very complex 
rule (if the destructor is not virtual and you delete through a base 
class pointer, and the actual most derived type has any additional data 
members or bases or introduces virtual functions or derives virtually or 
has a non-default destructor, *then* it's UB).

You're not getting rid of a category of undefined behavior. You're just 
limiting its applicability to a narrower area that is defined ultimately 
by the constraints of the exact implementations in use today.

This is fragile. It's hard to teach. It's hard to keep track of during 
maintenance. (Yeah, don't add anything to that class, or you'll get a 
bug that is extremely hard to track down. Add a string and you get a 
memory leak.)

> Or is there a good reason for this restriction?
I'm trying to come up with a case where the implementation could use the 
flexibility granted by the stricter rule in the standard. Can't think of 
it, but that doesn't mean there isn't one. In general, though, I think 
the simpler rule is just better by virtue of being simpler.

Sebastian


More information about the ub mailing list