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