Related articles |
---|
[7 earlier articles] |
Re: Pointers to "why C behaves like that ?" bobduff@shell01.TheWorld.com (Robert A Duff) (2002-11-17) |
Re: Pointers to "why C behaves like that ?" jamesp_spam_me_not@silver-future.com (James Powell) (2002-11-17) |
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-17) |
Re: Pointers to "why C behaves like that ?" mwotton@cse.unsw.edu.au (Mark Alexander Wolton) (2002-11-20) |
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-20) |
Re: Pointers to "why C behaves like that ?" marcov@toad.stack.nl (Marco van de Voort) (2002-11-20) |
Re: Pointers to "why C behaves like that ?" n368714668.ch@chch.demon.co.uk (Charles Bryant) (2002-11-20) |
Re: Pointers to "why C behaves like that ?" peter_flass@yahoo.com (Peter Flass) (2002-11-20) |
Re: Pointers to "why C behaves like that ?" peter_flass@yahoo.com (Peter Flass) (2002-11-20) |
Re: Pointers to "why C behaves like that ?" er+cc@cs.brown.edu (Manos Renieris) (2002-11-20) |
Re: Pointers to "why C behaves like that ?" md9slj@mdstud.chalmers.se (Stefan Ljungstrand) (2002-11-20) |
Re: Pointers to "why C behaves like that ?" torbenm@diku.dk (Torben Ægidius Mogensen) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" torbenm@diku.dk (Torben Ægidius Mogensen) (2002-11-24) |
[53 later articles] |
From: | "Charles Bryant" <n368714668.ch@chch.demon.co.uk> |
Newsgroups: | comp.compilers |
Date: | 20 Nov 2002 15:20:07 -0500 |
Organization: | Compilers Central |
References: | 02-11-059 02-11-071 02-11-083 02-11-100 |
Keywords: | design |
Posted-Date: | 20 Nov 2002 15:20:07 EST |
<thp@cs.ucr.edu> wrote:
... explicit declarations of variable types etc...
> Agreed. It's as though the compiler is continually giving an
> impromptu quizzes to the programmer, who has much better things to
> do with his/her time than to tell the compiler things that it can
> easily figure out for itself.
However the compiler is acting on behalf of all the future maintenance
programmers who would be quizzing the original programmer if only they
could travel back in time. Properly used, things like declarations
help to distinguish between what code was intended to do and what it
happens to do as an unintentional side-effect. Even the scope of a
variable can help considerably:
if (...) {
int i;
...
}
shows us instantly that the value of 'i' is dead at the end of the
block. Any scheme where a compiler automatically deduces the scope of
'i' is unlikely to be as clear as well as failing to detect when the
programmer accidentally uses an unrelated 'i' later without
initialising it.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.