> Curious. How do you know if you've added the 8001st warning that indicates that you did something ill-advised? It seems that such a huge warning count makes i

> Curious. How do you know if you've added the 8001st warning that indicates that you did something ill-advised? It seems that such a huge warning count makes it very hard for the compiler to tell you things. Well, doing a clean checkout of the master branch, noting N=number of warnings, then making your changes and comparing with N. At least that is what I did. It was not very popular, since no one ever tracked N on master at all. > I've generally found it quite practical to get warning counts to zero with some combination of fixing the issues and disabling warnings that have a poor signal-to-noise ratio. The one exception was /analyze builds. There I added filtering so that I could treat some warning types as fatal, and others would be reported on only when they were new. I completely agree that this is how it should be done. I vaguely remember that this is however quite complicated to achieve in the .NET ecosystem. Something about a library A being called in another project B respecting the disabled warnings of A when compiling A and B when compiling B, so you as a client could never disable warnings yourself (?). This was quite a while ago, and as I didn't work too much on A-type projects (only B-type projects), investigating it was never my responsibility. I just got told "It's not that simple" by the A-type employees.