2

When running cl.exe, you can specify the warning level.

cl /W3
cl /W4        # warn even more
cl /Wall      # all warnings on

However, the highest level, /Wall, seems impractical because it triggers warnings in Windows header files, such as in windef.h (Windows SDK for VS2010). The two most frequently occurring ones seem to be C4668 and C4820. So you can switch them off:

cl /Wall /wd4668 /wd4820

Still leaves you with C4255:

C:\SDKs\Windows\v7.0A\include\windef.h(230) : warning C4255: 'FARPROC'
C:\SDKs\Windows\v7.0A\include\windef.h(231) : warning C4255: 'NEARPROC'
C:\SDKs\Windows\v7.0A\include\windef.h(232) : warning C4255: 'PROC'

So you add that as well:

cl /Wall /wd4668 /wd4820 /wd4255

But others might crop up. And I might want to keep those warnings for my own code, just not have the output cluttered by warnings which did not originate in my code.

Is there a way to make the compiler apply different settings to standard headers than to my own code?

Update

Hmm, there's a similar question, and the answer is to go with /W4 instead of /Wall. Maybe it's not possible with MSVC to specify different settings for different files.

Community
  • 1
  • 1
Lumi
  • 14,775
  • 8
  • 59
  • 92
  • 2
    The compiler doesn't know anything about #include files. Such are the hazards of a preprocessor. #pragma warning is your friend. – Hans Passant Jul 19 '11 at 22:51
  • 2
    This kind of thing is really annoying - MS really should fix this to do what GCC does (allow certain include directories to be 'system' includes that are exempt from warnings) or they should modify the headers to be completely warning free regardless of the warning level (even if that's by using pragmas to disable the warnings being generated while the header is being processed). There's no point for anyone outside of Microsoft getting warnings from system headers, whether part of the compiler library or the SDK or DDK. – Michael Burr Jul 19 '11 at 22:53
  • @Hans Passant, that's a pertinent observation. :-) Still, GCC appears to be able to keep silent. Inserting suitable `#pragma`s into the source or whatever it does. Still, you're right, the compiler doesn't know about `#include` files. – Lumi Jul 19 '11 at 23:07
  • @Michael Burr: Amen to that. I was happy to see the `/Wall` warning level in VS2010 but quickly decided it wasn't worth the trouble of actually using it because of the million warnings – Praetorian Jul 20 '11 at 01:48

1 Answers1

3

Unfortunately, Visual Studio doesn't seem to have an option to specify warning levels for all header files found in a specific search path or something similar to turn off the warnings. I myself just stick with /W4 because of the exact problem you're describing.

The only way I can think of to get around this is to use the following in all your files wherever the offending headers are included:

#pragma warning( push, 4 ) // Saves the current warning level and sets it to 4
#include <Windows.h>
#pragma warning( pop )     // Restores the old warning level

#include "MyHeader.h"      // Include other 'non-system' headers

Note that I haven't actually tried this, so it may not work at all!

Praetorian
  • 106,671
  • 19
  • 240
  • 328
  • Thanks, that's useful! [MSDN link here.](http://msdn.microsoft.com/en-us/library/2c8f766e.aspx) Strangely, I seem to have to set the warning level to 3 in the `#pragma warning( push, 3 )` in order to shut up the annoying warnings I mentioned when running with `/Wall`. But when running with `/W4`, those warnings aren't triggered. – Lumi Jul 19 '11 at 22:58
  • @Lumi: That is odd; I typed 3 in my answer initially and then figured that I know 4 doesn't trigger those warnings, so that should be good enough :-) Anyway, I'm glad it worked. – Praetorian Jul 20 '11 at 01:46