{"id":3693,"date":"2010-12-14T09:56:00","date_gmt":"2010-12-14T09:56:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2010\/12\/14\/off-by-default-compiler-warnings-in-visual-c\/"},"modified":"2021-10-06T14:11:22","modified_gmt":"2021-10-06T14:11:22","slug":"off-by-default-compiler-warnings-in-visual-c","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/off-by-default-compiler-warnings-in-visual-c\/","title":{"rendered":"\u201cOff By Default\u201d Compiler Warnings in Visual C++"},"content":{"rendered":"

\"Image<\/a><\/p>\n

Greetings! My name is Jon Sturgeon; I\u2019m a developer in the Forefront team here at Microsoft. I\u2019m happy to be able to contribute to the Visual C++ Team Blog as a \u201cguest blogger<\/em>\u201d.<\/span><\/p>\n

One of my passions when writing C++ code has always been to use as many techniques as possible to find bugs earlier and earlier in the development process; obviously the earlier that bugs are found the easier and cheaper they generally are to fix. And if they can be found and corrected before the code is even built, everybody wins.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Compiler Warning Levels<\/h2>\n

I\u2019m assuming that everybody is familiar with the compiler warning level in the Visual C++ compiler. It is exposed through the \/W command-line switch and through the \u201cWarning Level\u201d item in the C\/C++ projects\u2019 properties page in the IDE:<\/span><\/p>\n

\"Image<\/a><\/p>\n

The relevant part of the property page shown above is for a brand-new C++ project created in Visual Studio 2010. As you can see, the warning level is set to \/W3 by default. However, I recommend you compile all your code at warning level 4 instead, since the increase in warning \u201cnoise\u201d can be fairly minimal and there are some useful warnings that are only active with \/W4 enabled. It is best-practice in many teams to ensure that all code compiles cleanly with \/W4 enabled and the related option to treat all warnings as errors (\/WX) is often also specified to ensure that code cannot be submitted without first addressing all the warnings identified by the compiler.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

 <\/p>\n

\/Wall<\/span><\/span><\/h2>\n

One warning option that isn\u2019t so well-known is \/Wall<\/a>, shown in the IDE below:<\/span><\/p>\n

\"Image<\/a><\/p>\n

This option (obviously) enables all<\/i> warnings in the compiler. This of course leads to the question of what warnings are not<\/i> enabled when \/W4 is specified? The answer can be found on this page<\/a> on MSDN which lists all the warnings that are \u201coff by default\u201d in the compiler. I\u2019m not going to walk through each and every warning in this list, but you can see that many of them are very trivial and \u201cnoisy\u201d warnings that you indeed are unlikely to want enabled on any realistic codebase. For instance, C4061<\/a> (\u201cenumerator in switch statement is not explicitly handled by a case label\u201d) is unlikely to identify any actual bugs and you\u2019d probably end up quickly disabling it if it was not off by default.<\/span><\/p>\n

However, as you scan through the list, you can see that some<\/i> of the warnings might identify potentially serious problems. A couple of my favorites relate to virtual functions: C4263<\/a> (member function does not override any base class virtual member function) and C4264<\/a> (no override available for virtual member function; function is hidden). In both of these cases, I want to know when my code triggers the warning, since there is quite likely to be an underlying bug that at the very least needs to be investigated.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

 <\/p>\n

\/Wall<\/span><\/span> in the Real World<\/h2>\n

Since just enabling the \/Wall switch on a real-world codebase is going to be unrealistic due to all the noise from the trivial warnings, is there a way to gain the benefits of some of these more useful warnings without suffering the pain of the less useful ones? Yes there is, and here\u2019s the way I\u2019ve approached this in the past:<\/span><\/p>\n

    \n
  1. Create a header file that every project in your codebase can #include.<\/span><\/li>\n
  2. Force-include this header file in every translation unit in your codebase by using the \/FI compiler option<\/a>.<\/span><\/li>\n
  3. Add #pragma warning(disable:<warning number><\/i>)<\/a> lines to the header file to disable the individual warnings that produce nothing but noise for your codebase.<\/span><\/li>\n
  4. Turn on the \/Wall switch for your codebase.<\/span><\/li>\n<\/ol>\n

    Alternatively, you can use the same technique to selectively enable individual off-by-default compiler warnings and rebuild without adding the \/Wall switch. However, I prefer the first approach, since that way I\u2019m making explicit choices about which warnings I want disabled. Additionally, any future warnings that the compiler team adds in future releases will then be automatically enabled when the compiler is updated, at which time I can decide if it makes sense to keep them enabled.<\/span><\/p>\n

    \u00a0<\/span><\/p>\n

     <\/p>\n

    Handling External Header Files<\/h2>\n

    One thing that you are likely to find when trying to build your codebase with many of these off-by-default warnings enabled is that some of the compiler\/SDK-supplied header files do not compile cleanly. I know that the Visual C++ & Windows SDK teams are very good at ensuring all the standard headers will compile cleanly at warning level 4, but there are no such guarantees when enabling \/Wall. Because of this, if you want to gain the benefits of building with some of these warnings enabled, you\u2019ll need a solution to this problem. Unfortunately the best option I\u2019ve found so far is to wrap the offending header file an a header of your own which temporarily disables the offending warnings and arrange for your code to #include that instead. For instance, if your code uses ATL, you may need to use a header similar to this: <\/span>\n<\/span><\/p>\n

    \n
    #pragma<\/span> warning(push)<\/span> #pragma<\/span> warning(disable:4265)<\/span> #pragma<\/span> warning(disable:4625)<\/span> #pragma<\/span> warning(disable:4626)<\/span> #include <\/span><<\/span>atlbase.h<\/span>><\/span> #pragma<\/span> warning(pop)<\/span><\/span><\/div>\n
    <\/pre>\n
    <\/p>\n<\/div>\n
    This header file temporarily disables three of the off-by-default warnings that atlbase.h can generate, includes the header, then re-enables the warnings so that they are active again for your code. If you can arrange for this small header file to be found in your codebase\u2019s include path before any of the system headers, you can name it atlbase.h so you won\u2019t have to modify any of your actual source code\u2019s #include directives.<\/span><\/p>\n
    \u00a0<\/span><\/p>\n
     <\/p>\n
    False Positives<\/h2>\n
    There are always false-positive scenarios with compiler warnings and the case is no different for the off-by-default warnings either. You\u2019ll have to use your judgment for each warning that you want to enable to see if the number of false positives that are generated in your codebase outweigh the potential for catching a real bug. One example where I think it can be worth suffering a few false-positives is C4265<\/a> – class has virtual functions, but destructor is not virtual. This warning, when enabled, is triggered by code like this:\n<\/span><\/p>\n
    \n
     <\/p>\n
     class<\/span> Animal { <\/span>public<\/span>: Animal(); <\/span>~<\/span>Animal(); <\/span>\/\/<\/span>not virtual<\/span> virtual<\/span> void<\/span> MakeNoise(); };<\/span><\/span><\/div>\n
    <\/pre>\n
    <\/p>\n<\/div>\n
    As you can see, the class has a virtual function, but the destructor is not declared virtual<\/i>. This can be a real bug that can lead to memory leaks if objects that implement the Animal base class are expected to be created on the heap and later deleted through a pointer of Animal * type. Or this can be a false-positive (i.e. not a problem) if these objects have an alternative destruction mechanism, such as the virtual IUnknown::Release() method that all COM interfaces employ. Consequently, if you choose to build your code with this warning enabled, you\u2019ll have false-positive warnings in any code that implements COM interfaces. At this point you\u2019ll have to make a decision about whether the warning is likely to catch real bugs in your code; if you want to keep the warning enabled, you\u2019ll have to temporarily disable it around the false-positive locations, using the #pragma warning method shown in the atlbase.h example above.<\/span><\/p>\n
    \u00a0<\/span><\/p>\n
     <\/p>\n
    Summary<\/h2>\n
    To sum up, here\u2019s my recommendations:<\/span><\/p>\n