Re: a barely useful option?

[Joe Buck <jbuck@synopsys.COM>]

> Joe Buck writes:
> > If the implementation were effortless, the warning could be put in but
> > modified to behave as follows: OK, so the base class has a non-virtual
> > destructor.  Consider this code:
> >
> > 	Base* b = new Derived(constructor-args);
> > 	....
> > 	delete b;
> >
> > will the right thing happen?  Well, if Derived has no additional data
> > members and does not declare a destructor, the right thing does happen, so
> > the compiler should never issue a warning in such a case.

Sol Foster writes:

> My understanding is that doing this results in undefined behavior
> according to the standard.  I can't cite the standard on this, alas, but
> the C++ FAQ claims that a virtual destructor *is* required if the base
> class destructor is non-trivial.

You are correct that the standard reads that way.  I challenge anyone
to name an existing C++ compiler in which the right thing does not happen.
Given the fact that the GNU, Microsoft, KAI, HP, Sun, SGI, Borland, etc
compilers all have this property, it is nonsensical to ask programmers
to make their code substantially worse in order to satisfy language
lawyers on this particular point.

Possibly the -pedantic flag should issue the warning, since the undefined
behavior is only theoretical.  It certainly doesn't belong in -Wall.

There was a similar issue on whether vector<T> elements are guaranteed
contiguous or not, it ended up getting settled by a defect report.  I
suspect that at least some of the committee would feel the same way on
this one:

Given that:
1.  We have nonvirtual 	Base::~Base.
2.  We have a derived class with no additional members (single nonvirtual
    inheritance) that does not declare Derived::~Derived
3.  Someone writes code like the above (deletes a Derived object through
    a Base pointer)

come up with an argument that the behavior is undefined is not equivalent
to "that's what the standard says".  For every existing compiler
Base::~Base will get called and the right thing will happen.

I claim that such code is completely portable.  If you disagree, you
need to show me a compiler *that someone might actually want to use*
in which something different happens.

> It may work in GCC, but there are no guarantees in other compilers, and
> so it is exactly the sort of thing one would like to be warned about.

No, people do not want to be told to make their code worse.  I have code
for which I expect a 3x performance penalty if I take the Effective C++
style recommendation here.