Why change the alert level for a specific alert in C ++?

Question

Visual C ++ Functions #pragma warning , which, among other things, allows you to change the warning level for a specific warning. Say warning X has level 4 by default and then

 #pragma warning( 3, X ) 

he will have level 3 from this point.

I understand why I temporarily turned off the warning, turned the warning into an error message, or turned on waring, which is disabled by default. But why should I change the warning level?

I mean that the warning level of a specific warning works together with the "warning level" option of the /W compiler, so I cannot imagine a setting in which I would like to change the level of an individual warning, since the warning emitted or will not depend on the project settings .

What are real examples of when I really need to change the alert level for a specific alert in C ++?

Answer 1

If you want to work at level 3 or 4, but want to see or not see a specific message, you can change its level. Of course, a pragma may not have any effect if the level of warning is not the one you think, but this life is with pragmas.

Answer 2

It is much simpler to accept one or two level 4 warnings that you want to detect and use a pragma to bring them to level 3 than to use /W4 and disable ( /Wd#### ) all the warnings you caused. Don't worry.

Answer 3

In some cases, when you work with outdated code and because the newer compiler becomes more sensitive, you can refuse the warning level for these modules to avoid thousands of warnings. Also, in some cases, when you interact with the generated code, you would like to refuse the warning level. for example, ANTLR generates C code that you process as a black box, so you do not want to receive warnings.

Answer 4

An example of where I use this is error C4996, where I move it from a level 3 warning to level 4. For example, the VS compiler warns that sprintf may be unsafe and suggests using the portable function sprintf_s instead. You can get a lot of these warnings, and instead of wading through all of these items to find real errors, I prefer to simply prevent them from being issued.

I know that I could define a macro for sprintf (and loads of other functions) instead that would support portability, and this should strictly be done, but in a large project, tracking and fixing all of these warnings is some effort, probably very few.

Answer 5

My experience is to handle warnings and errors and strive to create code without warnings. I know this may seem like a silly or too strict approach, but in the end it really pays off. Believe me!