Re: [boost] Towards a Warning free code policy proposal

Subject: Re: [boost] Towards a Warning free code policy proposal
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-08-28 15:17:51

I've casually followed this discussion and I'm sort of left confused.

My experience with trying to get to zero warnings is pretty simple.

I looked at each warning.

a) some were potential bugs and it was easy to fix - I fixed them.
b) some were potential bugs and harder to fix - I fixed them.
c) some were "cosmetic" bugs - e.g. declaration hide a base class variable - 
I fixed most of them.  But in some cases that was my explicit intention
d) some were too hard to fix/eliminate comparison between signed/unsigned - 
I just left them because I didn't know how to fix them
e) some were "cosmetic" warning which varied a lot between compilers. This 
started to turn into a game of "whack-a-mole" in that
that seemed to be never ending and would require a lot of compiler specific 
code - I left them.
f) some were in the library build - I considered these lower priority as 
they would only occur at install time.
g) some were in tests - I considered these slightly higher priority but 
still left some.  My reasoning is that it seems that users never run the 
test suite for libraries they use.  (another topic)
h) the rest would show in users code - I considered highest priority since 
this is were most users would see the warnings.

In addition, I use BOOST_SERIALIZATION_STATIC_WARNING in lots of places to 
flag code which is unlikely to produce what the user intended.  for example, 
exporting a derived class which is not virtual will not result in 
serializing a derived class through a base class pointer.

I'm not proposing anything.  I'm just saying that trying to get a "policy" 
on warnings seems likely to fail in my opinion.
Requiring 0 warnings is not realistic.

The only thing I can suggest is

a) expect a reasonable effort to minimize warnings
b) specific places where they can't be eliminated on all platforms should 
have a comment in the source code
at the right spot.
c) perhaps a short statement on some warnings which can't be surpressed in 
the libraries release notes or documentation

Robert Ramey