Why should one want to disable compiler warnings?

Question

This answer and the comments added to it show a way to disable several compiler warnings using #pragma directives.

Why would one want to do that? Usually the warnings are there for a reason, and I've always felt that they're good reasons. Is there any "valid case" where warnings should be disabled? Right now I can't think of any, but maybe that's just me.

Answer 1

I've only ever had one situation where I disabled a warning. I consider warnings errors so I wouldn't normally release with warings. However while devloping a API at a customers I faced the issue that a method that was needed in a migration phase by one application and that no other should ever use had to be included in the library.

The best way I could find to tell all users of the API that they shouldn't call this method was to mark it obsolete. That however ment that the one valid use case was marked as a compile warning.

Eric Lippert has written a few posts about warnings where you'll find information about how the compiler team thinks about warnings.

Internal fields of Internal types

Unused using directives are not marked with warnings

Answer 2

Here are a few warnings where the documentation gives reasons why you might want to disable them:

• http://msdn.microsoft.com/en-US/library/4bw5ewxy(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/sa4zat99(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/9x19t380(v=VS.80).aspx

Other examples include warnings about using depreciated methods if you know you still want to use the old method or having private members that are never read locally, but with reflection instead.

In my experience C# has less need for disabling warnings than other languages such as C++. This is largely because, as Eric Lippert says in his blog, they "try to reserve warnings for only those situations where we can say with almost certainty that the code is broken, misleading or useless."

Answer 3

Many indispensible Java libraries have never been updated to eliminate the need for unsafe typecasts. Suppressing those warnings is necessary so that other more important warnings will be noticed and corrected.

Answer 4

Valid or not, it is sometimes done to bypass the "treat warnings as errors" directive on the build server.

Other than that I can't think of any either. Disabled warnings are usually a sign of an "ugly hax"...

Answer 5

Last time we disabled certain warnings, it was because an intern had left us with bad code. I've got it working a lot better, with clear conversion boundaries replacing the haphazard data representation.

In the meantime, we needed to compile it in, and we wanted the "warnings are errors" option on, so we suppressed some of the warnings.

Answer 6

Currently, the only warning I ever ignore is

  warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)  

Because microsoft does not implement the C++ specification (the documentation even says they don't!) and allow functions to declare specific throws and all functions can only throw either throw() or throw(...), i.e nothing or everything.

From HelpViewer 1.1:

 A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications. 

Answer 7

I do embedded work and I seem to remember a time or two when I've disabled warnings because I was doing something that looked useless to the compiler, but which actually had real-world effects in the hardware.

The only other time is when I'm working on codebases with disparate ideas of some data structure (like how to represent arrays of bytes - char or unsigned char?). In these cases I might disable the warnings because the alternative is to spend days going through the code and either modifying one portion, or putting in hundreds of casts.