C++ Logo


Advanced search

Subject: Re: [std-proposals] Make abstract classes non-deletable if no virtual destructor available
From: connor horman (chorman64_at_[hidden])
Date: 2020-03-25 08:52:21

On Wed, Mar 25, 2020 at 08:14 Henry Miller via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Practically there is no difference. However I think that there are subtle
> differences that make my wording of the idea a little bit better. Either
> way I fully expect that large code bases can switch to the newer standard
> that has this and the only problems will be existing bugs don't compile. (I
> know some people reading this have the resources to check that statement, I
> don't)
> Consider
> Child::destroyWithoutCleanup() {
> ...
> delete static_cast<base*>(this) ;
> }
> I would hope nobody writes code like that, (it does look c++98 to me) but
> it should be legal even if it never is written. This subtle change of
> wording makes a difference in how it works.

That's undefined behaviour unless base has a virtual destructor, in which
case the cast is useless (it still calls Child's destructor)

> This change of wording also means if there is some real situation we
> didn't think of there is a work around.
> class base {
> public:
> ~base() ; // do not make this virtual because...
> } ;
> If I thought the above was a real situation I'd go farther and ask for
> ugly syntaxes like reinterpret_cast<virtual>(=false) which already looks
> like something that will set off alarm bells in the head of everybody who
> reads the code.
> Last this gives the standard consistency with the general guildline that
> if you have any virtual functions your destructor is either virtual public
> or non-virtual protected. Elevating this guideline in the standard would be
> a nice bit of consistency I think worth going for.
> On Tue, Mar 24, 2020, at 13:24, Kilian Henneberger via Std-Proposals wrote:
> > Both, making the automatically generated destructor protected (how you
> > would word it) and making the delete call ill-formed would lead to the
> > same result.
> > Personally I do not see any advantage of one over the other.
> >
> > Am 23.03.2020 um 23:24 schrieb Henry Miller via Std-Proposals:
> > > I would word this as if there are any pure virtual functions the
> automatically generated destructor is protected. It gives the result you
> want by default, anyone who wants the virtual destructor already has to
> declare it. And if there really is a reason to have a non virtual public
> destructor it should be verbose enough to call attention to that unusual
> situation.
> > >
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups