Experimental Physics and Industrial Control System
|
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" <[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
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|