I never understood why C and C++ compilers try to recover from errors and continue parsing. Almost always, the first error generates a stream of bogus errors that will disappear as soon as the first one is fixed. After several years of experience, I simply stopped looking at any error except the first one of every file. I rerun the compiler and then do that again until there is no more errors. Is it a common practice?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
Sometimes the errors are unrelated. I find it easier to look at a list of errors and fix the root cause of a series of related errors, then fix the next un-related error. If the project is large and takes a while to build, I find working in this manner less frustrating than fix first error, recompile, repeat... |
|||||||
|
|
It depends on the compilation time. For example, if I know that I just changed a master header that will trigger a rebuild of the entire project, I'll certainly take a closer look at the rest of the error stack and see if I can fix some of them. That gives me a better feeling when I stand up to make coffee while the compiler runs. |
||||
|
|
|
If there is a gap in the line numbers, the compiler probably did recover and then found another error. Usually only try to fix one error in each bunch though. |
|||
|
|
|
Yes I do the same, unless I am using the compiler to help me refactor in which case I like the full list of errors :) |
|||||||||||
|
|
Better compilers will produce better results and give you more useful errors after the first one, often through some kind of automatic correction of the errors so that presumably good code can at least be checked. But then, I'm used to working in Java, in Eclipse, where syntax typos are instantly detected and easily corrected, and other compiler errors tend to be more diverse and easier for the compiler to recover from. I can only assume that it's similar when working in Microsoft's IDEs and others in C++ or C#. |
|||
|
|
|
Yes - or at least I skim them. It is pretty easy to figure out if the errors are related (usually a look at the line number is enough) and I like fixing them all in one pass and then recompiling. |
|||
|
|
|
I do this (to read the errors past the first one) only if the 1 cpp compilation is very long. Or not available. Then I prefer to make sure I fixed everything I could identify in the compiler errors as unrelated to the first error. When your cpp file can be compiled alone and does in less than a second (or you have an "intellisense" pointing errors before the compilation even started) you don't have to do this most of the time. I currently work on a project where I can't compile one cpp alone (and I don't have the hand on the build system so I can't change that O__o) and some cpp files can take more than ten minutes to compile (even after a lot of effort to reduce that, we only cut it by to 50% of the original compilation time...). In this kind of very long compilation setup, you tend to think a lot first before hiting "build"... and even think a lot after, to maybe find bugs before the compiler as you're certainly faster to get them mentally than it. |
|||
|
|
