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 |
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