A warning typically means that while the code is legitmate with respect to the C++ syntax, the compiler suspects that it might be doing something else than what the programmer intended. Since the computer can't guess what's in the head of the programmer, there's no safe way for it to automatically fix it. If you have so many warnings, it's probably best to watch out for very common types of warnings, pick one of these, and focus on fixing that warning everywhere in the code, ignoring other warnings. Most of the time you'll quickly be able to spot certain patterns, and fixing these errors should therefore be possible almost without thinking after a while. It will still take time, but that way it's probably a lot faster than working on all warnings by order of occurrence. P.S.: if your goal is refactoring the entire code, then eliminating warnings is the last of your concerns! First you need tests, to ensure that the refactored code really produces the same results. Then you need to start with the lowest level functions, and then work your way up. Chances are, that changes in your low level functions require adjustments higher up, and that could very well affect code that currently issues warnings. It would be pointless to fix warnings first and then change that same code again due to low-level refactoring, so you better don't do that so early!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)