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: Q: destructors in C++ interfaces (abstract base classes)
From: Doug Murray <drm@slac.stanford.edu>
To: Ralph Lange <Ralph.Lange@bessy.de>
Cc: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Fri, 17 Nov 2006 14:57:55 -0800
Title: Re: Q: destructors in C++ interfaces (abstract base classes)
Hi Ralph.  I’m finally getting a chance to look through some source code!

I think making the destructor a protected virtual method sounds good.

But I think making the destructor public or protected (or private) has no impact on whether to make it virtual.

In general, a virtual destructor should be defined for any base class with virtual methods, and that applies to pure abstract classes too.

You might be aware – one can also specify a pure abstract destructor:
    protected: virtual ~wireSendAdapter() = 0;
as long as the inline definition is included later:
    inline wireSendAdapter::~wireSendAdapter(){}

This keeps the class definition pure abstract, satisfies the compiler and doesn’t add overhead that isn’t already there.  It’s basically the same as a non-pure class destructor that you suggested – there’s no real advantage in this situation.  The Vtbl is still present, but with a null entry for the destructor.  The compile will fail if the inline definition isn’t included.


-doug



On 11/17/06 2:04 AM, "Ralph Lange" <Ralph.Lange@bessy.de> had this to say:

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



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

Navigate by Date:
Prev: Q: destructors in C++ interfaces (abstract base classes) Ralph Lange
Next: RE: destructors in C++ interfaces (abstract base classes) 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: Q: destructors in C++ interfaces (abstract base classes) Ralph Lange
Next: RE: destructors in C++ interfaces (abstract base classes) 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 ·