To disable a set of warnings for a given piece of code, you have to start with a “push” pre-processor instruction, then with a disabling instruction for each of the warning you want to suppress, and finish with a “pop” pre-processor instruction.įor example, in our case, the sequence would look like that: // up until this line, the warning is active The disabling sequenceīefore we get into the code for each compiler, there is something in common in the sequence of disabling a warning between all three compilers.
We’re going to see how to disable a warning on gcc, clang, and on Visual Studio, and in case your application has to compile on all three, how to write code that disable a warning on all compilers. Visual Studio identifies warnings with a number (here, 4100), whereas gcc and clang use a string (here, -Wunused-parameter).Īs you can imagine, that will lead to different code to disable the same warning between the compilers. You can observe that they don’t have the same text and–more importantly for our purpose–the warning is not identified the same way. Here is gcc’s warning, which is the same as clang’s: warning: unused parameter 'b' Īnd here is Visual Studio’s warning: warning C4100: 'b': unreferenced formal parameter The compiler is able to emit a warning for this. But all compilers don’t emit the same warning. Let’s take the example of the warning that warns you that you didn’t use one of the parameters of a function: void f(int a, int b) Let’s see how to do that and keep code expressive. Second, if you’re following the best practice of transforming warnings into errors, by activating the -Werror flag in gcc and clang for example, leaving a warning in is simply not an option.įortunately, C++ lets you block the emission of a specific warning for a portion of code. This doesn’t scale if there are several warnings you decide to leave, because at each build you’ll have to check them all to see if a new warning hasn’t popped up and needs to be checked. This warning will always remain here, and you’ll have to check that it’s the one you decided to leave in every time you compile the code. First, you will no longer have a clean build with no errors and no warnings.
In such occasions, letting the warning in the compiler’s output has several drawbacks. In the vast majority of cases, the compiler has a good reason to emit them, and in the vast majority of cases, they point out to an oversight in your code.īut in a minority of cases, you may want to deliberately write code that triggers a warning. As explained in item 53 of Effective C++, you should “Pay attention to compiler warnings”.
0 kommentar(er)
