Stewart, Robert wrote:
Peter Dimov wrote:
(Apologies of losing track of the quoting.)
Warnings often indicate real problems.
A "warning policy" is only needed for warnings that do not indicate real problems.
That's a naive position.
Thanks.
If one is in the habit of ignoring warnings (suppressed or otherwise), one may miss the error. Warnings can alert the developer to a problem before anyone notices it in real use. Consequently, the warnings policy is to build at a reasonably high warning level and to emit none.
This is a reasonable warnings policy for a company, or a project, but is not a Boost warnings policy. The Boost warnings policy needs to - state whether a warning is considered a bug, - state whether and how a developer should deal with reports (and trac tickets) that a warning is emitted, - ensure that warnings are seen by developers, - ensure that a warning, once eliminated, stays eliminated, - ensure that warnings are not introduced into other developers's code. Note that if you replace "warning" with "bug", the items above no longer make sense - that's because we already have a policy for bugs and don't need another one.