C ++ compiler warnings: cannot be refused

We went to Cloud4Y about programming in the cloud and about which programming language can rightly be considered the most “cloudy”. Is it a long time, have we come to discuss the mistakes of the cops - about their dual nature: and it’s impossible to ignore everything, and pay attention to everyone ñ it’s not long for the mind to move. Today we will present you with a small script handling warnings of the compiler, which will allow you not to miss a blunder and keep the nervous system in order.

We often see compiler warnings about areas of code that have potential problems or bad style. Sometimes they point to code that doesn't really work, so don't ignore them.

You probably saw one or two compiler warnings when compiling C ++ code . If you are working on a voluminous project, then you see hundreds of such warnings every day, and after a while some of them become familiar to you. You no longer just know them, they become annoying background noise that appears whenever you start compiling.

Do not ignore compiler warnings.

Of course, these warnings can not be annoying; moreover, they most often occur for ideally working code that definitely does not contain bugs.

But rest assured that one of several thousand compiler warnings does make sense. Sometimes we write code that compiles, but something doesn't work the way we expected. So how, in the name of Habr, to determine which warning indicates a real error? How to distinguish it from hundreds of others, in which the code is valid? Do you really need to spend so much time reading them all? It is almost impossible.

Accept the “no warning” policy

If it’s really fair, there are only two things you can do with compiler warnings — ignore them or get rid of them. Ignoring them means throwing a tool into the bin that will help prevent bugs. Would you dismiss the presence of one or two serious errors? Probably not.

You can say that if there are only a few compiler warnings, you can live with it. Here's the thing: you probably check your code relatively often (at least we hope so). This means that you often need to compile, and this entails compiler warnings. You will pay attention to them. Perhaps you will still pay attention to them if you receive 6 warnings instead of 5; but will you notice the 11th ? 20th ? 52nd ?

Getting rid of the warnings is the only acceptable and safe for the psyche option.

Change your code to get rid of the warnings.

Although sometimes we want the compiler to just keep silent about a specific warning, it is better to just change the code. If the code is not clear to the compiler, then there is every chance that it will not be clear to the person either.

Clarifying your intentions in code is often enough to silence the compiler. Some compilers may give hints on how to solve certain warnings. Let's look at the frequently occurring assignment warnings in a conditional context:

For Clang, it looks like this:

The second case that underlies this warning is: sometimes we write a = b, when we mean a == b.

While other compilers just warn that the task we wrote looks rather strange in this section of code, CLANG helpfully tries to guess what we could have in mind.

The first pointer simply tells us how to correct the warning if the task was actually intended. GCC has the same warning and suggestion to correct, but without providing an alternative:

Many prefer CLANG, as it allows us to guess what the correct solution is. This is much better, because it gives the opportunity to find a bug in the code, which would not have happened, we automatically accept everything that the compiler offers.

Even if the assignment was indeed planned, accepting the compiler clause and adding a pair of parentheses may be the wrong decision.

From the point of view of pure code, we must separate the assignment and the condition. It is much more convenient to have one line for each task, that is, in essence, apply the Principle of Uniform Responsibility on a line-by-line basis:

Do not fix compiler warnings automatically; make corrections only deliberately.

Tell the compiler what type of warnings are important to you.

There are several ways to work with the compiler and not receive warnings. Naturally, writing code that even a poor compiler can understand is the best solution. However, it is also possible to tell the compiler which warnings you are interested in and which are not.

Compiler flags

Every compiler we know provides the ability to select the alerts you want to see. You can turn off different groups of alerts, and sometimes you can reassign individual alerts to a different alert level. Usually these features are provided as command line parameters in the IDE settings. This means that you may have a single place — preferably your build script — where you can apply these settings.

What warning flags to use? It depends in part on the compiler, since different compilers emit different warnings, and some of them may be not just erroneous, but delusional.

Some warnings may be too pedantic for your taste or for your style of writing code, although we still haven’t encountered any warnings that have no basis. (In our opinion, it is generally better to look through all the warnings in order not to miss the important one).

Standard flags for most warnings are Wall, Wpedantic, Wextra (many of the compiler flags for warnings start with W).

If you are just starting to apply a “no warning” policy for your project, you will most likely receive hundreds or even thousands of warnings if all of them are included. Start with a lower level of warnings. Record the toughest warnings and gradually type your alert level.

If you are exposed to moments of laziness, or if you have colleagues who oppose a “no warning” policy, then turning them off is not so easy. Someone may want to check the code containing the corresponding warning. In the end, it turns out that this is not an error, the code is compiled and will probably work as intended. Thus, a bunch of warnings will resolve, one after another.

To avoid such a waste of time, you can strengthen the “no warning” policy by switching warnings to errors. Thus, errors will be difficult to ignore - otherwise the build will simply fail. You can do this with separate warnings, as well as with all warnings at the same time. Set the appropriate -Werror flag for Clang and GCC and / WX for MSVC.

Pragma Directives

Compilers often use special #pragma directives to enable or disable specific code warnings. These directives should be considered as a temporary solution, because they have their own flaws:

• Disabling warnings with #pragma silences the compiler for the entire remaining unit. If you want to disable this warning only once, be sure to enable it right after the line of code with the question. Enabling #pragma for the header file and deciding not to include warnings again silences the compiler for each source having a header, as well as for each header after #pragma
• The #pragma warnings directives are not portable. The identifiers for each individual warning vary for different compilers, as well as the #pragma format. Sometimes compilers issue warnings about unknowns #pragma - and you definitely don’t want to write to the GCC warning #pragma that he should ignore these MSVC warnings. To conclude them with #ifdefs is clearly not the best solution.

There are times when using #pragma doesn't suit you.

As an example, there are headers for third-party libraries that you cannot change, and the compiler complains about them. Another example is with a once written embedded language: it used operator overloading in an unusual way that ignored the built-in priority of C ++ statements.

The compiler helpfully suggested adding additional brackets. This could be the right solution if the operators were applied to numeric values. In order for the DSL code to be read, in this case, you need to silence the warning without touching the code, here you can disable the warning using #pragma along with an explanatory comment.

Instead of conclusion

You can set up the compiler, telling him which warnings you are interested in and which are not; use command line arguments for this, or #pragmas directives if necessary. Try to be as strict as possible, do not add too many exceptions. This means careful use of #pragmas and deviations from your standard command line arguments.

PS Sometimes none of the above methods is a realistic solution. Then just use the shut-up command for the compiler.