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

Subject: Re: [boost] Towards a Warning free code policy proposal
From: Raymond Wan (r.wan_at_[hidden])
Date: 2010-08-29 01:52:58

Hi all,

On Sat, Aug 28, 2010 at 01:26, vicente.botet <vicente.botet_at_[hidden]> wrote:
> Hi all,
>
> Last year there where two long threads about Boost Warning policy. If I'm not wrong nothing was concluded. I think that we can have two warning policies: one respect to the Boost users and one internal for Boost developement.
>
> We can consider that Boost headers can be used by the users as system headers, so no warning is reported for these files. The main advantage I see is that it allows the users to don't mix the warnings comming from Boost and their own warnings.
...
>
> Please, let me know if this policy could satisfy the needs of the Boost users and the developers.

As a user who is somewhat following the discussion, I have to say that
the approach used by gcc in terms of handling warnings is good.
Warnings are shown and you have to add flags such as -Wall to disable
them.  That at least forces users to do something because of the
warnings -- either act on it by looking at their code or realizing
that the warning is unimportant and to find the flag that would remove
it.  Perhaps a more viable solution is to produce warnings and errors
that could be searched in a part of the Boost documentation (i.e.,
dedicated to dealing with warnings) that says what caused the warning
and how to disable it if the user is satisfied that it is not
important.

I can see why this issue would be brought up -- boost warnings are
intimidating to users.  But (IMHO), removing warnings will make users
not knowledgeable in Boost (such as myself) to becoming more sloppy.
Instead of that, maybe keeping the warnings but having documentation
specifically explaining how they can be suppressed might be a bit
better than having them off by default for users.

Another idea is that I tend to use colorgcc to color the output from
gcc.  Perhaps modifying colorgcc or producing a separate wrapper which
colors warnings based on severity might be another idea...

Ray