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 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:
#pragma warning(push, 0)
// 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.