How to make warnings persist in visual studio

Question

Suppose I have files a.cpp and b.cpp and I get warnings in a.cpp and an error in b.cpp. I fix the error in b.cpp and recompile -- since Visual Studio doesn't have to recompile a.cpp, it doesn't remind me of the warnings it found before.

I'd like to somehow have the warnings persist; however, I don't want it to treat warnings as errors (I'd like it to still compile/run even with warnings). Is this possible?

Answer 1

Rebuild your project or recompile only the a.cpp file. Warnings are output by the compiler, so you won't get warnings for files not included in the current compilation.

You can save your current build output going to the Output pane and pressing Ctrl+S (defaults to output-build.txt if I don't remember bad.)

In your project settings I think build output messages can be saved on files. Check it and tell your results.

Cheers

Answer 2

You could go into the project settings and set all warnings as errors in the C/C++ tab (category: General).

Answer 3

Essentially, you're out of luck. The C++ compilation will discard all of the errors and warnings. Because it only recompiles .CPP files that have a missing .OBJ file (i.e. the ones that had errors and failed last time), you'll only see the errors.

You have a few options. Off the top of my head:

• Write a macro that responds to the build complete event. If it sees any warnings, it could delete the .OBJ file. The .CPP file would be compiled again next time. Unfortunately, this means that your program may not run without recompilation.
• You could write a macro that works the other way: on build start, look to see if there are any warnings, and then delete the .OBJ file.
• Write a VS addin that remembers warnings until the .CPP file is compiled again.

Answer 4

As Hernan already said, add a custom build step that makes a copy of the intermediate file that contains the build results (warnings). Not sure how to do naming for this, but you could create a bat file that gets called as a custom build step.

Why you would want to save warnings is beyond me. Treat them as errors, or ignore them or pragma/disable them.

Answer 5

Given that you don't want to recompile the files that cause the warning, one option you might have is to write a small utility that filters the output of the compiler for warnings and writes them to the .cpp file as a //TODO comment.

Then the IDE will place them in the todo list.

I'm not aware of anything that does this out of the box, but it probably wouldn't be too difficult to whip up.

If you don't want the utility mucking around with the actual source files (and I'm not sure I would), you might want to have it write the //TODO comments to a dummy 'todo.cpp' file and have that file in the project. Then they'll show up in the todo list and since the file is nothing but comments, it won't affect the build. Just make sure the utility is smart about not adding duplicates to the list. A macro could be written to take you from the todo.cpp line to the corresponding actual location of the warning.

Answer 6

I'd strongly recommend running with warnings as errors as much as possible, and certainly in all the code you're writing yourself. It is way eaiser to fix the warnings here and now, than wait until later and try to do them all in one pass.

There are several reasons why you want to run with warnings as errors:

• The majority of warnings actually indicate that there is a problem with your code.
• If you have a lot of warnings, you won't notice if a new one appears in the middle. I've seen this happen a lot.
• If there is a warning which you think is bogus or you for some reason just can't fix it right away, you can switch it off. Use the /w option or suitable #pragma. Note that you can switch it of for only a particular file, or even in a particular place in your code. If you still want a notice when compiling, but a #pragma message there.
• If there is code which is outside of your control, but you just have to compile it into your program, switch of warnings for that particular module or source file, or even run it without /WX. Chances are you aren't modifying the code anyway, so point 2 is probably not so relevant.

I really cannot see any valid reasons for not running with /WX (or -Werror).