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:[email protected]]
> 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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|