RE: a barely useful option?

[Jan Reimers <janr@molienergy.bc.ca>]

As another example.  The idea of expression templates is critically
dependant on having non-virtual base class destructors (that work).  In
this paradigm, multiple nested template classes are used to convert
"array arithmetic" into suitable/tight loops.  All the expression
template classes are inline and completely optimized away at compile
time.  One virtual base class destructor would result in significant
code bloat from all the v-tables.

JR  

> ----------
> From: 	Joe Buck[SMTP:jbuck@synopsys.COM]
> Sent: 	Monday, August 09, 1999 2:00 PM
> To: 	colomon@ralf.org
> Cc: 	gcc@gcc.gnu.org
> Subject: 	Re: a barely useful option?
> 
> > 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.
> 
> 
> 
> 
>