Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Seweryn Habdank-Wojewodzki (seweryn_at_[hidden])
Date: 2009-11-05 13:50:36

Dears,

> I realize these can get pretty busy-body at times, but if the user sees 
> several pages of warnings when building Boost it doesn't look so good.

We are using boost with -Wall and /W4 warning levels. In the company we
have policy that requires minimalization of the number of warnings for those
two levels in paraller.

There are some issues:
- fixing problems is time consuming
- GCC sometimes warns when MSVC not at all at any level, off course
there is a similar situation in other way round.
- MSVC gives opportunity to suppress concrete warning in concrete place,
GCC not.
- In bigger projects, that are using templates, flood of warnings causes
that important issues are not higlighted, because every instantiation cause
the samewarnings and some modules before cleanning may generate
2000 warnings where there are e.g. 100 warnings of one type in one place.

All above concerns not only to boost but to our code as well.

To avoid exhausted suppressions from the supporting libraries as well as
operating system headers we are providing fake headers that suppress
warnings and includes real header.
For you it might be that you may create fakes for OS headers and suppres
their warnings.

In GCC there is nice option to check only header, by compiling that header.
This option helps to clean up header without any context and helps to check
if all includes are sufficient.

To summarize, at the end of the day we are really happy when any of our
modules has no warnings, because further development may concentrate
on issues that are important for next step and not start with thinking what
warnings we have to suppress or what we have to provide to filter warnings
from third party libraries or OS providers - this is for GCC where there is
no suppresion mechanizm.

However I want to say that even if we suppressing warnings from boost
I must say that your code is very good in comparison to others.

Best regards,
Seweryn Habdank-Wojewodzki.