Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk