NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/misc/3502

Text File | 1992-11-06 | 4.3 KB | 87 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!cs.utexas.edu!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
From: [e-mail] (J. Giles)
Subject: Re: Pointers
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Los Alamos National Laboratory
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 5 Nov 1992 18:48:31 GMT
Lines: 75

In article <[e-mail]>, [e-mail] (Randy Crawford) writes:
|> [...]
|> As many have pointed out, C has arrays.  When you prefer to use an array
|> in C, you can and should.  To quote the bards K&R, "pointers are not arrays".
|> (If they didn't say that, some other wise soul surely has.)

When I pass a multidimensional array to a procedure as an argument,
C turns it into a pointer to the base type of the array.  If the
various dimensions of that array are variable, C does *NOT* permit
it to be declared as a conformable array in the procedure.  Period.
I can cite the restriction directly from the standard document if you'd
like.

C has actually committed two sins against array users - both as a
result of this coercion to pointer.  First, it is not notationally
convenient in C to program procedures which handle variable sized
conformable arrays.  Second, the coercion to pointer makes it
impossible for the C compiler to *locally* determine whether
incoming pointers are aliased.  If the user were offered a choice,
then he could declare the incoming arguments as pointers if he
wanted to *allow* aliasing, and he could declare them as arrays
(with or without variable dimensions) when he wanted to disallow
aliasing.

|> [...]
|> As for using pointers for dynamic memory access or dynamically extensible
|> data structures -- "a rose is a rose by any other name". [...]

Except that a pointer `rose' is redolent with the stench of allowed
aliasing while Fortran 90's ALLOCATABLE variables (for example)
are *NOT*.  Similar high-level data structures (like sequences,
trees, etc.) could be defined with similar advantages.  Internally,
these would still probably be implemented with pointers *PLUS*
a constraint against operations which could cause aliasing which
pointers don't provide.  This *exactly* corresponds to the idea
of hiding GOTOs under structures like WHILE, IF/ELSE/ENDIF,
SELECT/CASE, etc..  The GOTOs are still there *PLUS* constraints
which make the code easier to read and maintain as well as making
the code easier for the compiler to optimize.

|> >[...]
|> >Pointers are the GO TO of data structuring.  They are used to create
|> >spaghetti data structures in the same way GO TO is used to create
|> >spaghetti code.  If it's at all possible to avoid using them, don't
|> >use them.  As with GO TO, you only use 'em when you GOT TO.  Also,
|> >as with GO TO, there are ways to make your use more structured if
|> >you *must* use them.
|>
|> In my opinion, no language leads to worse spaghetti-like data structures
|> than Lisp, a language without pointers and dependent on garbage collection
|> to do for the programmer what s/he prefers not to do.  That's swell.  For
|> those (like yourself) who prefer to let the language dictate efficiency,

On the contrary, I *DEMAND* that the user have control over efficiency
as directly as possible.  One of the most severe *killers* of efficiency
is the fact that pointers *might* be aliased and the compiler cannot
tell - so it *must* inhibit optimizations.  I oppose C because it
*denies* me control that I believe it is important to have.  I don't
say that languages shouldn't have pointers/GOTOs, I just think the
user should have the choice to use additional structures with more
directly optimizable semantics than these raw tools.

|> [...]
|> If the justification for avoiding gotos appears to you to be equivalent
|> to the rationale behind pointer use, you really should get away from C as
|> quickly as possible.

No, the justification for avoiding GOTOs doesn't just appear to me
to be equivalent to the rational behind pointer *avoidance*, there
is a demonstrable one-to-one correspondance between the two concepts.
If you disagree, take it up with C.A.R. Hoare - who I'm more inclined
to believe than you.

--
J. Giles