Hi all, On Sat, Aug 28, 2010 at 01:26, vicente.botet <vicente.botet@wanadoo.fr> 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