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

[David Blaikie]

On Mon, Jul 23, 2012 at 1:48 PM, Steve Ramsey <clang at lucena.com> wrote:
> On Jul 23, 2012, at 12:40 PM, David Blaikie wrote:
>>> Which reminds me: I don’t follow the standard proceedings at all, but why shouldn’t the implicitly declared destructor in a class with a virtual member function not be made virtual by default? The only other option that makes sense is to make it protected and nonvirtual, though that is probably less often what the class designer wants. I thought this might change in C++11, and find it makes even more sense given the new rules about special member functions.
>>
>> The doBaseStuff calls virtual functions from a base reference (perhaps
>> the author doesn't want the code bloat of a template, or it's
>> statically compiled in another library, etc) but the object itself is
>> never polymorphically owned so it's not polymorphically destroyed and
>> thus doesn't need a virtual destructor.
>
> Hence why I mentioned protected non-virtual destructors. If your destructor is public, no force on Earth will keep some ninny from calling it directly at some point, documentation and good sense be damned.

Right, sorry - then the issue is if you have non-abstract non-final
classes which are admittedly less common, but I'd find it surprising
if the language made choices/defaults based on that being such a
vanishingly narrow case as to be irrelevant.

Anyway, sorry for derailing the thread (I think what needed to be said
was said by the first replies: the code has UB) - this is probably a
conversation for the C++ standards body.

>> derived's dtor doesn't need to be virtual as shared_ptr's type erasure
>> machinery guarantees that it'll be destroyed the same way make_shared
>> created it, with a derived*, not a base*.
>
> Once again, a protected nonvirtual destructor guards against this. But, once again, since it’s the less frequently desired behavior, it would make sense for the default to be a virtual public destructor for classes that have a vtable anyway, and let implementors explicitly declare it otherwise if that’s what they desire.
>
>                         Steve
>