Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!orion.oac.uci.edu!cerritos.edu!arizona.edu!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: C's sins of commission
Message-ID: <26295@megaron.cs.arizona.edu>
Date: 12 Oct 90 00:45:47 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 59

In article  <65265@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
]From article <14972@cbmvax.commodore.com>, by skrenta@cbmvax.commodore.com (Rich Skrenta):
]> [...]                                                  Are the programs
]> any more readable because I say
]> 	int i; a[i]
]> to dereference instead of
]> 	struct foo *p; *p ?
]
]Yes!  Because, a[i] and b[j] are guaranteed _not_ to be aliased...

But a[i] and a[j] don't have that guarantee.  So there are a few
aliasing problems that are easier to solve with arrays.  No big deal.

]...  The pointer syatax _may_ be used to simulate arrays, but
]you might be planning to use it for dynamic memory, strings, recursive
]data structures, run-tim equivalencing, etc..  How does the reader know
]that the pointer will not be used in any of those ways - he knows the
]array won't be.

No he doesn't.  In a language without pointers, the array might be
used to simulate pointers, and the pointer-simulation used for one of
the above purposes.

]  Each of these features should have separate syntax since
]they are separate features.

C-style pointers struck me from my very first exposure as a simple and
elegant way of merging various things that are only _apparently_
different.  I don't suppose you would be willing to just admit that
people have different tastes and give up your crusade against
pointers?

I'm willing to recognize that you prefer to divide the world up into a
bunch of seperate boxes.  You ought to recognize that others prefer to
integrate different things into the same box.  It is simple hubris to
try to convince others that your personal preferences are somehow
objective and that their preferences are misguided.

]  Forcing them all to masquerade as pointers
]only confuses the person maintaining the code - and doesn't give the
]compiler enough information to adequately optimize.

Funny, I've never been confused by any of the above uses of pointers
(with the possible exception of run-time equivalencing, I don't know
what you mean by that...).

As to optimization, I will admit that it is _harder_ to optimize code
with pointers.  You have never convinced me that it is less _possible_
to optimize pointers.  I say let the machine (or the compiler-writer)
do the work.  If my mental picture of a solution to a problem involves
pointers, then the language should let me _express_ the solution with
pointers.  Yes, yes, _you_ don't think I should be picturing problem
solutions with pointers.  I happen to disagree with you, and so do
thousands of other C programmers.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman