Re: Pointers to "why C behaves like that ?"

"Dr A. N. Walker" <anw@merlot.uucp>
24 Nov 2002 01:26:25 -0500

          From comp.compilers

Related articles
[19 earlier articles]
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 ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-24)
Re: Pointers to "why C behaves like that ?" nicola.musatti@objectway.it (Nicola Musatti) (2002-11-24)
Re: Pointers to "why C behaves like that ?" fjh@cs.mu.OZ.AU (Fergus Henderson) (2002-11-24)
Re: Pointers to "why C behaves like that ?" anw@merlot.uucp (Dr A. N. Walker) (2002-11-24)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" stephen@dino.dnsalias.com (Stephen J. Bevan) (2002-11-24)
[41 later articles]
| List of all articles for this month |

From: "Dr A. N. Walker" <anw@merlot.uucp>
Newsgroups: comp.compilers
Date: 24 Nov 2002 01:26:25 -0500
Organization: School of Mathematical Sciences, Nottingham University, UK.
References: 02-11-059 02-11-083 02-11-100 02-11-109
Keywords: design
Posted-Date: 24 Nov 2002 01:26:25 EST

Charles Bryant <r368714668.ch@chch.demon.co.uk> wrote:
><thp@cs.ucr.edu> wrote:
>> Agreed. It's as though the compiler is continually giving an
>> impromptu quizzes to the programmer, [...]
>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.


I think there is a danger of assuming that all programs fit
one familiar model. Your environment may be one in which the needs of
maintenance programmers are important. Mine is not. It used to be;
especially from the point of view that my maintenance programmer could
be me, six months down the line when I've forgotten how the code
worked. But these days, my programs are usually small run-once
thinggies, or small do-some-simple-task thinggies, and they will
never be "maintained" in the way that an operating system is.
Increasingly, my big "programs" in fact consist of bundles of shell
scripts with occasional diddy-C stuff mixed in.


Am I unusual [in this respect!]? I've no idea. Of course,
I'm not writing commercial packages. I'm also not paying real money
for the compilers and operating systems I use, so perhaps I have no
"right" to an opinion. Bleeagh.


> 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.


As it happens, I'm in favour of declarations in "serious"
programming languages [and against them in shell scripts]. But I'm
unconvinced that they are even part of this software-engineering
argument; "int i;" does not tell me what code using "i" is intended to
do, only what may be done with it in a legal program. Properly used,
comments, assertions and other devices may be used to distinguish
these things. The difference is that, in C, declarations are
compulsory while comments and assertions are optional. I'm certainly
not saying that's a bad thing; I'm not even sure that Tom was. But if
you insist on everyone using hammers, while screwdrivers and drills
are optional, then nails come to be preferred to screws. Or
something.


--
Andy Walker, School of MathSci., Univ. of Nott'm, UK.
anw@maths.nott.ac.uk


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.