A few years ago I was in a job interview, and the development manager was gloating because he had squashed all compiler warnings in the code, and then added the gcc
-Werror switch to the build, so that warnings now caused the build to fail. At the time, I thought "That's annoying overkill". My feeling was that compiler warnings didn't live very long -- after someone saw one a few times, they would fix it.
But I've changed my mind. Where I work, the team had even been doing without
-Wall for many years. They had been using
-pedantic. In other words, the warnings were all noise, and no signal, since the pedantic warnings don't tell you about potential bugs in your code, just about adherence to language standards. Moreover, they were completely happy to ignore all compiler warnings -- even those for things so dangerous that gcc warns about them without any warning switches, like 64-bit size issues. I now understand why someone would insist on
Really, the best set of warnings for g++ is
-Wall -Wextra -Werror. [If you have an older gcc, like the 3.2.3 that's stock on RedHat 3, use
-W instead of
-Wextra.] When we switched these on recently, there were thousands of unique warnings. Many of them were harmless in the end of the day, but there were dozens that indicated serious code bugs and/or crashes waiting to happen.
Of course, you can disable some of the
-Wextra warnings. On our RedHat 3 build, we find it convenient to add these disabling flags:
-Wno-parentheses: too picky
-Wno-unused-parameter: provoked by <fstream>
-Wno-deprecated: provoked by <strstream>
In the best possible world, we would use <sstream> and wouldn't need
-Wno-deprecated. But that's a battle for another day. For today, I'm just very happy that we have real warnings turned on, and that they get attention due to