Good approaches to enforce building with increased warning level for new C++ code

Question

I've inherited a large C++ codebase for several Windows applications that successfully is in use by many customers.

• The codebase is large, >1mill LOC.
• The codebase has a history of 15+ years.
• The codebase is in some areas dominated by C programming style and/or not very modern C++ style, e.g. not using Standard C++ collections and algorithms.
• The codebase has unfortunately only been compiled with warning level 2 (/W2 in Visual C++). I would like to increase to level 3 (/W3) to increase security and prepare for 64-bit.

The most problematic point in the increase to warning level 3 are the many warnings received involving signed/unsigned mismatches and I recognize that it will be a very large task to resolve all those for the existing codebase.

What would be a good approach to ensure and enforce that new code committed to the codebase are compiled with the increased warning level?

In more general terms the question could be rephrased to how you enforce increased programming quality into new committed code. If you don't do anything, new code has, in my experience, a tendency to be affected and styled similar to existing code, rather than being improved to more modern standards.

Answer 1

I would even go as far as going to warning level 4 (/W4).

---

Since you're using Visual Studio, it's quite easy to suppress bothersome warnings like signed vs unsigned comparision:

#pragma warning(disable:NNNN)

Where NNNN is the number of your warning. Now put all those disabled warnings in a header file (say, "tedious_warnings.h") and force-include that header file everywhere - Project Properties -> C/C++ -> Advanced -> Forced Include File.
Later on, or better, ASAP, remove the force include and work your way through the warnings, since most of them are quite easy to fix (size_t instead if int, etc).

Answer 2

Perhaps you could create new code in separate DLLs or Libraries. That way you can enforce your higher warning level (and I would say go for /W4 and be prepared to turn off a few of MS's dafter warnings rather than settle for /W3) without having to wade through 1000s of warnings from the old code.

Then you can start working on cleaning up the old code, a bit at a time, when there is time -- making sure you have suitable unit tests in place to avoid breaking it by accident of course.

Answer 3

you may not like the answer...

remove the warnings by correcting the issues.

i'm very picky about warning levels; even i ignore warnings which i don't need to correct, especially when the warning level is high and build times are high. meanwhile, new ones slip in (in large codebases). removing them incrementally doesn't work very well, in my experience -- they tend to get ignored if the noise is too high, or it is not enforced.

you need to reduce the warning noise so people can see the warnings they add (at the warning level you desire).

to reach the compliance level you want/need, make it a priority.

if you don't know whether the conversions/comparisons are valid, you can always use a template function with an error action (assert, throw, log) to perform the logic when in doubt.

it can be a slow/tedious process, but it's also a good way to learn the codebase.

i typically start at the libraries highest in the tree, or those which are reused most often. once a library meets a standard, maintain that standard.