NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/cplus/18172

Text File | 1992-12-20 | 3.8 KB | 67 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!spool.mu.edu!umn.edu!csus.edu!netcom.com!erc
From: [e-mail] (Eric Smith)
Subject: Re: compiler error reporting
Message-ID: <[e-mail]>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <[e-mail]>
Date: Fri, 18 Dec 1992 10:13:07 GMT
Lines: 56

In article <[e-mail]> [e-mail] (Brian J Tarbox) writes:
>Why are c++ compilers so bad about reporting errors?

My C++ parser doesn't have that problem, and in fact its first
application is "C++ Clarifier" which is a program to give you a "second
opinion" error message to compare with your compiler's error message,
in those cases where the compiler's error message is so cryptic and
frustrating that it seems like it might waste a lot of your time
finding out what it means.  I'm going to start beta testing C++
Clarifier in about a month or so, with the Microsoft 32-bit C++
compiler as the initial platform.  Would you like to be a beta tester?

Some people might find it hard to believe that I would put in all the
considerable time and effort to develop a C++ parser just to check for
errors, and they would be right, because C++ Clarifier is actually just
an application I thought up after getting my parser working.  My
original and continuing intent was/is to develop the world's best C++
development environment.  After the C++ Clarifier beta test is started,
I will be working on an extended preprocessor, a class browser, and
several other programs that will use my parser, but the development
environment as a whole won't be done until after most of its parts are
already widely used.

As for your question, why are C++ compilers so bad about reporting
errors, I think the main reason is that C++ is one of the hardest
languages to parse.  First, preprocessing is considered a separate
stage, and most C++ parsers keep it separate such that they lose
context information between the stages because there is no convenient
way to retain it.  Second, there are a lot of complications and ways to
lose context information in the main parser.  For example, when parsing
a class, the inline functions have to be parsed at the end of the
class, even if they appear earlier, so they will see the declarations
that appear after them in the class.  But if an error is discovered in
one of those functions, the parser will have already parsed to the end
of the class.  A lot of parsers designed without enough consideration
for error reporting are unable to place such errors in their correct
location because they don't keep track of the original location when
they move the functions to the end of the class.  There are a lot of
other examples of where the parser can go wrong and lose the error
context.  But the main problem is really that making the parser work at
all is very hard, and when it finally works the programmers are
reluctant to spend a lot of time and effort rewriting it to improve its
ability to place errors in their correct locations.

I spent considerable time and effort solving those problems in my
parser, and one of the reasons why I was willing and able to do so was
that I used object oriented programming, which makes rewriting the
code, redesigning it, rewriting it again, etc., much easier.  For a
program as complicated as a C++ parser, there is no way to get it right
the first time.  It's just too complicated.  So anyone who wants to
write a high quality C++ parser had better plan on redesigning and
rewriting it several times, and had better design the original code in
such a way as to make it easy to rewrite major parts of it as many
times as needed to get it right.  It's also very important to make it
as fast as possible, and that usually requires redesigning and
rewriting major parts of it at least a few extra times.