Re: Why C/C++ errors are SO obscure/devious??
- From: gordonb.n7t2w@xxxxxxxxxxx (Gordon Burditt)
- Date: Tue, 30 Aug 2005 17:28:02 -0000
>I'm not a C newbie, but I'm teaching C programming (well... FIRST
>programming and then C) to other guys these days and it's driving me to
>some reflexions on the language.
>
>It's not uncommon to forget a } writing code, and at compiling time get
>an error 18956778 lines after the mistake, in an otherwise absolutely
>correct piece of code.
The compiler doesn't know that this is where the } is missing. There
may be several other places that would also be correct code.
>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.
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?
>Why can't a compiler give more accurate informations about errors?
The compiler is not psychic. It often can't tell whether you
declared the variable with the wrong type, or forgot one level
of indirection on the reference to it.
>Shouldn't this save time, stress and money?
When it guesses WRONG, it will cause stress and waste time and money.
>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.
>Choose which definition is the right one:
How would I answer this to indicate that (3) is a typo and (2)
should have been declared static? I have not memorized where all
of the references are, so I can't say which reference should go
with which function off the top of my head. There are also ways
to answer TWO messages like that (about the same function/variable)
where my answers cannot be coded in valid C short of globally
renaming one of the functions/variables. Oh, yes, when the compiler
is compiling foo.c, it DOESN'T know that if it does a global rename
of a function, it has to fix up the references in bar.c, a bunch
of clients being developed on another computer in another country,
and the distribution disk on CD-ROM.
I don't want the compiler to try to be interactive when I'm compiling
an open-source package. Most likely the configure script is including
the wrong libraries or include files, and the message you suggest
will be entirely misleading. Also, I don't want it writing on
source code behind my back for any reason.
>This is "interactive compiling", isn't it?
I want my source code to reflect the actual source code used, not
a slight approximation to it.
>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.
>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.
Gordon L. Burditt
.
- Follow-Ups:
- Re: Why C/C++ errors are SO obscure/devious??
- From: Kenneth Brody
- Re: Why C/C++ errors are SO obscure/devious??
- References:
- Why C/C++ errors are SO obscure/devious??
- From: Massimo Soricetti
- Why C/C++ errors are SO obscure/devious??
- Prev by Date: Re: understanding format specifiers
- Next by Date: Re: Why C/C++ errors are SO obscure/devious??
- 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
|
