C++ Logo

sg12

Advanced search

Re: [ub] Non-virtual destructor call

From: Sebastian Redl <sebastian.redl_at_[hidden]>
Date: Fri, 13 Dec 2013 14:17:47 +0100
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

Received on 2013-12-13 14:33:49