Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Gerry Quinn
Date : Sun Jul 31 2005 02:22 pm

In article <42eb8672$0$14673$ed2619ec@ptn-nntp-reader02.plus.net>, 
usenet@jdh30.plus.com says...
> Gerry Quinn wrote:
> > Typically an interpreter will stop on the first error.  Compilers in my
> > experience usually carry on until a fixed number of errors (e.g. 100)
> > have been found, and then stop.
> 
> Lots of compilers don't do that.
> 
> > Usually in C++, if there are eight errors found, there really are about
> > eight.
> 
> C++ isn't worth using unless you use the STL, IMHO. Error messages from all
> of the compilers that I have seen are completely unwieldy when using the
> STL. For example, the following code contains an extra "const":

STL is just a library.  I got on well enough with the MFC collection 
classes for a while, although I do prefer STL now.  I still use MFC 
CString.  The rest of the stuff is just functions you might need once 
in a while.

[STL example - I'm not sure I would call it C++]

> > When there are 100 errors, you left out a curly bracket 
> > somewhere above the first one, or something like that.
> 
> What you are saying is true in C but not in C++.

It's true in C++ in my experience - STL errors are not as common as 
simple syntax errors.  Perhaps if you are trying to emulate some kind 
of functional language with C++ you will get more.

There is a freeware add-on called STLFilt that is supposed to parse 
these errors for common compilers - haven't tried it.  At the end of 
the day an uninformative error message still does most of its job as it 
tells you there is an error and approximately where.

- Gerry Quinn

.