Experimental Physics and
Industrial Control System
| 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Q: destructors in C++ interfaces (abstract base classes) |
| From: | Doug Murray <[email protected]> |
| To: | Ralph Lange <[email protected]> |
| Cc: | EPICS Core Talk <[email protected]> |
| Date: | Fri, 17 Nov 2006 14:57:55 -0800 |
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" <[email protected]> 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 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
- 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 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·