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?
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.
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#.
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.