|
Boost : |
Subject: Re: [boost] Towards a Warning free code policy proposal
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-08-29 04:58:05
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Raymond Wan
> Sent: Sunday, August 29, 2010 6:53 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Towards a Warning free code policy proposal
<snip>
>
> 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.
https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines
tells you quite a lot about warnings, including gcc and MSVC
(It's a bit thin on other compilers - more info please).
> 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.
I'd like to see Boost getting rid of warnings that come from its code, so
that all warnings are relevant to the user.
The above, and references therein, (written for Boost developers) may still
be useful to users.
Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk