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?
1
-
I guess I only read the first ones, but I don't work with thousand million source file solutions, so that helps.– CoderCommented Mar 30, 2011 at 18:41
Add a comment
|
8 Answers
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...
answered Mar 30, 2011 at 17:31
FrustratedWithFormsDesignerFrustratedWithFormsDesigner
46.3k7 gold badges129 silver badges176 bronze badges
-
4+1: Mind you, if the project is large and takes a while to build, it's wise to not change too much between compiles so that you can find any problems you introduced relatively easily. Commented Mar 30, 2011 at 19:03
-
1I agree that in the case your compilation time is very long, it may be useful to look for other unrelated errors, but I would prefer to fix the dependency problems that cause those long incremental builds...– alexk7Commented Mar 31, 2011 at 15:38
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.
answered Mar 30, 2011 at 18:02
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 :)
-
Many modern IDEs have refactoring tools available at the click of a button, so refactor-by-compiler-error is not necessary if you have access and abilities with such tools. Unless you prefer it... Commented Mar 30, 2011 at 18:28
-
1Yes but my primary work IDE VS has none for C++ :( When there is no tool I will find a way! Commented Mar 30, 2011 at 18:45
-
1Visual Assist X from Whole Tomato adds refactoring to VS for C++. Commented Mar 30, 2011 at 19:00
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.
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.
answered Mar 30, 2011 at 17:37
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.
It's quite common to do as you do. I usually tell interns or novice programmers overwhelmed by the number of errors to ignore almost all of the errors except for the first one. It's most likely a real error that needs to be fixed, and not a misleading phantom error caused by a previous one. Some (most?) compilers have the option to stop compiling after the first error for this reason. Build systems usually can be configured to stop after the first file that has errors as well.
However, there are reasons for continuing to compile after detecting errors too. For example, you may want to count how many files have errors, or to see if an included header file causes errors in more than one file.
