Experimental Physics and Industrial Control System
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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024