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: Ralph Lange <Ralph.Lange@bessy.de>
To: Jeff Hill <johill@lanl.gov>
Cc: "'EPICS Core Talk'" <core-talk@aps.anl.gov>
Date: Sat, 18 Nov 2006 18:26:12 +0100
Hi Jeff,

I'm happy with not jumping off a cliff, but I still not fully understand the steepness....


Jeff Hill wrote:
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.
The HP-UX compiler does.

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.
In which case the public default destructor (that the compiler adds if you don't define a destructor explicitly) in all your interface classes leaves that gate to destruction wide open, correct? Wouldn't that force us to make the destructor protected to prevent external code using it?

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.
I'm not a Windows expert. But all C++ literature says the explicit equivalent to the default destructor is an empty inline function. So you're saying the explicit equivalent might produce code while the default doesn't? Doesn't sound very obvious to me, but - I'm not a Windows expert - so I may be walking on thin ice here.

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.
I don't see the structural problem. It seems completely legal for an interface to not allow deleting objects though itself. Declaring the destructor protected sounds like the natural way to do it - that's also what I find online searching for the topic. Otoh - having a non-virtual destructor in a base class does introduce (at least) a memory leak that is definitely worth warning about. I mean: Any code that calls delete on one of those interface classes in EPICS Base uses the default destructor and corrupts the system in the way you mentioned, right?

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.
Again: I won't jump off that cliff for the heck of it, but - do you really prefer the current situation with the public destructors lurking around to get a chance to crash the system? (I'm exaggerating, admitted.)

Well, I'm not committing these changes now, but I still feel they should be.

Cheers,
Ralph


References:
RE: destructors in C++ interfaces (abstract base classes) Jeff Hill

Navigate by Date:
Prev: R3.14.9 changes commited so far Jeff Hill
Next: Re: R3.14.9 changes commited so far Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: destructors in C++ interfaces (abstract base classes) Jeff Hill
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 
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 ·