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

[David Blaikie]

On Mon, Jul 23, 2012 at 11:55 AM, Steve Ramsey <clang at lucena.com> wrote:
> On Jul 23, 2012, at 9:52 AM, Matthieu Monrocq wrote:
>> So I would argue against the owner here: what is the cost, really, of declaring the destructor virtual ? (especially since there is already another virtual method anyway)
>
> Well, if you want to avoid deprecated behavior, once you declare a virtual destructor, even if it’s just defaulted, you also have to declare the five other special member functions to maintain the existing behavior.
>
> 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.

I'm not sure if this answers your question, but here's a simple
example that's not uncommon/unreasonable:
{
derive d;
doBaseStuff(d);
}

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.

Another less obvious example:

{
std::shared_ptr<base> sp = make_shared<derived>();
doStuff(sp);
}

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*.

>
>                         Steve
>
> P.S. If it were me, I’d just suck it up and fix the base class. The maintainer here seems to be spending more time arguing than it would take to implement the correct action.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev