I am a huge fan of warnings in C and C++. I have always taken warnings from the compiler
seriously, and tell my students to get used to taking them seriously, too.
Warnings are the compiler’s way of telling you:
“Something you wrote in your source code was ambiguous or might result in undefined
behavior, so I created an executable program anyway, made some assumptions for you (which
are probably wrong), and your code may or may not work some or all of the time.”
In virtually all of my projects, I strive for completely warning-free compilations, so that when a
warning does appear, it really gets my attention and I take care of it immediately. In fact, in
some projects, I have enabled the “Treat Warnings as Errors” option, to prevent any warnings
from inadvertently slipping through. (Within Visual Studio, go to Project | Properties |
Configuration Properties | C/C++ | General | Treat Warnings as Errors.)
I crank up the warning level to its available highest setting. In Visual Studio C and C++ projects,
that’s EnableAllWarnings, or /Wall on the compiler’s command line. This level allows the
compiler to give you the most warning feedback possible, including warnings that are turned
off by default. (Within Visual Studio, go to Project | Properties | Configuration Properties |
C/C++ | General | Warning Level.)
But what if you’re using header files that you don’t control, and they contain warnings? These
might be header files that come with the environment, legacy header files, or third-party
header files. Ideally, you could contact the owners of these files and tell them to clean up their
acts, but that’s not always practical. So, the warnings remain, and there are more and more of
them as you crank up the warning level. The noisy warnings from these header files can have a
tendency to hide the warnings generated by your own code, unless you take the time to
painstakingly sift through all the warnings after every build, looking for only the ones that are
coming from your own code.
To quiet this noise, and focus on the code over which you actually have control, you can use
a #pragma to temporarily turn off warnings around specific offending header files, and then
immediately turn warnings back on again. For example, the <windows.h> header file
generates quite a few warnings when the warning level is set to EnableAllWarnings, or /Wall.
Here’s how to turn off only the warnings coming from this header file:
// Quiet the warnings from the windows.h header file
#pragma warning(push, 0)
#include <windows.h>
#pragma warning(pop)
// Your code here.
Another example of a Visual Studio supplied header file that generates some warnings is
intrin.h, which deals with compiler intrinsics. I have worked with dozens of third-party header
files that also generate warnings, as well as ancient legacy header files filled with warnings,
and this technique can be applied to them as well.
That said, you should not turn off warnings around any of your own header files. You have full
control over them, and you should want to see the warnings in your code and clean them up.