Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · 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:[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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System