Re: [boost] [serialization] non-virtual destructors in 1.33.1

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-22 23:54:02

FWIW - I saw the warnings on my own system. I use comipler_status_2 on my
system which does show boxes with warnings.

I decided to leave it alone for the following reasons.

a) "Official" boost policy is that there is no requirement for
a library to make special accomodation for non-conforming
compilers
b) Emision of a warning is not an error in any case.
c) gcc allows one to supress the warning in the command line.
d) I made the destructors non-virtual and placed them
in the protected section because I specifically did NOT
the object destructor called from anywhere but the most
derived class.  This was to address some issues where
the derived class can be defined in a dynamically loaded
DLL while the base class can be defined in the
serialization library or DLL.  If the derived class DLL is
explicilty unloaded while an object defined by it still
exists there will be a program crash.  This can be
hard to avoid as some of the base class instances
are static variables destroyed on program exit.
e) Doing things the way I did permits any errors in
this code to be detected at compile time.

Having said that, and (hopefully) the code having
been tested, I'm hopeful that making the destructor
virtual for gcc won't hurt anything.  Doug has asked
me to add it in so this warning won't appear on this
compiler.

So that's what we're going to do.

Robert Ramey

Jeff Garland wrote:
> On Tue, 22 Nov 2005 22:11:33 +0100, Matthias Troyer wrote
>> On Nov 22, 2005, at 9:15 PM, Kim Barrett wrote:
>
>>> However, do you (and the rest of the boost community) really want to
>>> release this in it's current state? Should every development group
>>> using
>>> gcc and the serialization library have to locally work around this?
>>> How
>>> many queries about this are there going to be on the boost mailing
>>> lists
>>> between now and a release that addresses this? And how many
>>> potential users of the library are going to try it, get large
>>> numbers of warnings,
>>> and go elsewhere?
>>
>> I would like to support this opinion. We have several libraries and
>> applications based on boost and usually get a large number of user
>> complaints for each warning produced when compiling our codes.
>
> We really need a volunteer to fix the regression system so that
> developers can actually see warnings -- be aware that when things
> compile with warnings there is NO indication in the regression
> system.  So rather than just fix the one problem, we need someone to
> work on the general problem so we can start tracking warnings as an
> issue before release rather than after...
>
> Jeff
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost