Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: destructors in C++ interfaces (abstract base classes)
From: "Jeff Hill" <johill@lanl.gov>
To: "'Ralph Lange'" <Ralph.Lange@bessy.de>, "'EPICS Core Talk'" <core-talk@aps.anl.gov>
Date: Fri, 17 Nov 2006 18:23:02 -0700
Hi Ralph,

As I recall these are the issues surrounding what you are "fixing".

1) GNU seems to be having an internal debate over this warning. I notice
that some gcc versions have it and that others don't, and that they are
flopping back and forth several times. No other compilers have this warning.

2) There _are_ situations where the pure virtual interface class doesnt need
to have a destructor if the code is going to crash anyways if they delete
using a reference to the pure virtual interface class. This is often the
case with my code because I use free lists and we don't want to use the
delete operator which by default tries to return the free list allocated
object to pool - RIP. There are ways around this, but much of CA was written
before I learned such tricks.

3) On windows if we use epicsShareClass we like to not have any code
implemented in the class as this causes problems with the DLLs. The empty
destructor adds code to the pure interface class. This cant be guaranteed to
be avoided with inline functions because the compiler is free to make an
ordinary function as it sees fit, and also in the past it has been said to
be pure evil to make any virtual function inline.

4) We can't make the destructor protected with out actually implementing one
(see point three above).

5) Getting rid of warnings just so they wont be seen w/o fixing the
underlying structural problems (perhaps I need to reroute delete to use my
free list) maybe isn't a good ideal.

And maybe others as it is a complex issue. I have certainly been on the
verge of doing what you suggest in the past but backed away from the cliff
after considering it from several vantage points, and I don't claim to
remember all of the ramifications at the moment.

Sorry about slow response - I have still some backlog remaining before the
release goes out.

Jeff

> -----Original Message-----
> From: Ralph Lange [mailto:Ralph.Lange@bessy.de]
> Sent: Friday, November 17, 2006 3:04 AM
> To: EPICS Core Talk
> Subject: Q: destructors in C++ interfaces (abstract base classes)
> 
> Hi -
> 
> I'm working on finally getting the gcc4 warning fixes committed, that I
> recently wrote about.
> 
> Almost all remaining fixes are about avoiding the countless warnings of
> the type
> 
>   ../comBuf.h:48: warning: 'class wireSendAdapter' has virtual functions
> but non-virtual destructor
> 
> 
> by adding an empty (inline) virtual destructor to those classes, which
> are usually interface classes (abstract base classes).
> 
> Browsing through some online documents and blogs, I found the most
> comprehensive approach being:
> 1. If it is intended to delete an object through the interface, the
> destructor must be virtual. Overhead is low, as there are already other
> virtual functions in the class.
> 2. If deletion through the inferface is not intended, the destructor
> should be protected to enforce this. There's no need for the destructor
> to be virtual in that case, as it is not to be used anyway.
> 
> Right now, the compiler will create an empty public non-virtual
> destructor, which seems definitely not the right thing to do. Our cases
> seem to all fall in category 2., but making the non-virtual destructor
> protected doesn't fix the compiler warning.
> 
> What about making the destructors virtual and protected? Sounds like a
> fair deal, making both the compilers happy and preventing from deletion
> through the interface.
> If I don't hear any objections (Jeff?), I will go on and commit these
> changes tomorrow (I'm on late shift on Saturday).
> 
> Cheers,
> Ralph


Replies:
Re: destructors in C++ interfaces (abstract base classes) Ralph Lange
References:
Q: destructors in C++ interfaces (abstract base classes) Ralph Lange

Navigate by Date:
Prev: Re: Q: destructors in C++ interfaces (abstract base classes) Doug Murray
Next: R3.14.9 changes commited so far Jeff Hill
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: Q: destructors in C++ interfaces (abstract base classes) Doug Murray
Next: Re: destructors in C++ interfaces (abstract base classes) Ralph Lange
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·