Re: Why C/C++ errors are SO obscure/devious??
- From: Kenneth Brody <kenbrody@xxxxxxxxxxx>
- Date: Tue, 30 Aug 2005 14:59:49 -0400
Gordon Burditt wrote:
[...]
> >Or, sometimes in my journeys I got errors
> >reported in a file, checked and found it correct, and discovered it was
> >caused by an error in another file. And in general, I noted that many,
> >if not all, error messages from the compiler are VERY short and cryptic,
> >while a couple of words more could sometimes help a lot in understanding
> >what's wrong and where, for newbies. Well, not only for them... maybe a
> >compiler switch --NOOB_ERR_MSGS could be very handy for some people :o)
>
> Something like changing:
> undefined symbol _main
> to
> undefined symbol _main - Did you forget to define main()?
>
> might help, but in many cases, the compiler error message would start
> to resemble legal documents if it tried to produce a detailed message
> but still reflect that the compiler DOES NOT KNOW which of many possible
> mistakes you made. Even above, it may not know that main() is supposed
> to be a function, not a local variable.
BTDT. There was a FORTRAN compiler at the school I went to, specifically
designed for the FORTRAN class projects. It ran extremely fast, but
produced extremely poor code. This made sense as it would take numerous
compiles before the code would compile error-free, and the executable
would only be run once. (In other words, any time spent trying to
optimize the output code would exceed the time saved in running it.)
Being aimed at those learning FORTRAN, its error message were _very_
verbose. As in a missing comma might generate half a page of text
describing what you "might" have meant.
> One example: almost every time I get a syntax error in a system-supplied
> include file (not the ANSI C headers, but ones that come with the
> OS), it's because I forgot to include a prerequesite header (often
> <sys/types.h>) that typedef'd something *BEFORE* this header. But
> the compiler never suggests: syntax error on line 115 in <sys/proc.h>,
> possibly pid_t should be a typedef but isn't? In such a situation,
> I wonder how many WRONG suggestions it would come up with, when an
> include file really is missing but it has to guess what should have
> been in it?
The above-mentioned FOTRAN compiler would have listed them all.
[...]
> >Another example: have you ever met the error line "Multiple definitions
> >of..."?
> >
> >For example, why can't a compiler start a negotiation "on the fly" like
> >this:
> >
> >ERROR: Multiple definitions of <variable|function|method> X.
> >X defined:
> >1) <here1> as variable
> ><line of code definition...>
> >2) <here2> as variable
> ><line of code definition...>
> >3) <here3> as function
> ><line of code definition...>
>
> Up to this point, this would be a nice message, listing all the
> definitions.
FYI - My C compiler does list the file/line which first defined the
variable/prototype.
[...]
> >Why not? Why the compiler
> >can't simply ask us, in doubt, and on response modify sources
> >accordingly on its own, in this case and in other similar? This would
> >ease the programming effort a lot.
>
> If the compiler modifies source code, it had darn well better use
> *MY* style and ONLY *MY* style.
I don't want the compiler modifying my source any more than I want
Windows' chkdsk to "automatically fix errors".
Now, bringing up the source in a text editor, letting me fix it, and
then restarting the compile might be a nice thing. However, the
"interactive development environment" of the compiler I usually use
lets me double-click on an error message, and it brings up the
corresponding source file, with the cursor on the line which gave
the error. And, I can do that for each error that it gave, without
having to restart until I'm done.
> >What are your opinions on this matter?
>
> Clearer error messages that give more details would often help.
> I think I've seen messages that complain about the type of a
> variable (on a line with many variables in it) without naming the
> variable in question.
>
> Compilers modifying source code is a bad idea. The only exception
> I'll make is for void main(), where the compiler should *DELETE*
> the offending source code.
:-)
Perhaps "i = i++;" should result in the entire file being replaced with
ASCII-art of nasal demons?
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@xxxxxxxxx>
.
- References:
- Why C/C++ errors are SO obscure/devious??
- From: Massimo Soricetti
- Re: Why C/C++ errors are SO obscure/devious??
- From: Gordon Burditt
- Why C/C++ errors are SO obscure/devious??
- Prev by Date: Re: object code from which compiler
- Next by Date: Re: pointers
- Previous by thread: Re: Why C/C++ errors are SO obscure/devious??
- Next by thread: Re: Why C/C++ errors are SO obscure/devious??
- Index(es):
Relevant Pages
|
