on Wed May 02 2007, "Jonathan Franklin" <franklin.jonathan-AT-gmail.com> wrote:
On 5/2/07, David Abrahams <dave@boost-consulting.com> wrote:...
If you treat warnings as errors and if bjam has an option to "keep going" as much as possible, then you get builds as far as they can go (i.e. all the warnings) and builds fail if there are warnings. Then I think you don't need to depend on the regression reporting tools for the rest of time, atleast for this stuff.
It would take a lot to convince me to require that Boost builds with all warnings enabled and treated as errors. There are just too many "nuisance" warnings out there, and since GCC gives us no way to explicitly suppress warnings in code, we'd have to write convoluted (and sometimes even inefficient) code just to silence them.
This is certainly the case with the MS compiler, who even at lower warning levels tends to make spurious comments about your code (not really warnings at all).
At least it gives me the #pragmas I need to silence them.
However with gcc (and possibly other compilers), building w/ -Wall -Werror is tenable, and is usually the Right Thing. We have done this on the last several (extremely large) projects I have worked on.
In my experience it's the Right Thing for certain common coding styles, but completely wrong for others. For example, GCC has a warning about a derived class whose base doesn't have a virtual dtor. It's actually *impossible* (not just inefficient or convoluted) to implement is_polymorphic without generating that warning. -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com