Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!samsung!uunet!brunix!drc
From: drc@cs.brown.edu (David R. Chase)
Newsgroups: comp.lang.misc
Subject: Re: Relationship between C and C++
Message-ID: <33316@brunix.UUCP>
Date: 20 Mar 90 03:20:01 GMT
References: <8432@hubcap.clemson.edu> <5200048@m.cs.uiuc.edu>
Sender: news@brunix.UUCP
Reply-To: drc@cs.brown.edu (David R. Chase)
Lines: 42
Organization:

In article <5200048@m.cs.uiuc.edu> robison@m.cs.uiuc.edu writes:
>This is not the first attack on pointer arithmetic that I have seen.
>Why is pointer arithmetic denigrated so much?  The C-style pointer
>arithmetic seems to me to implement a fairly simple abstraction,
>roughly equivalent to ``a tape and a read/write head.''
>Most C implementations do not do bounds checking on pointers, 
>but I fail to see why pointer arithmetic is inherently evil.
>
>Can anyone clue me as to the basis for pointer paranoia?

Well, one good reason is that in many cases where it pays to do
pointer arithmetic (loop invariant code, reduction in strength,
redundant expression elimination), the compiler can do (using
algorithms published more than 5 years ago) about as good a job as you
can, except that it won't occasionally make mistakes, and it will
remember to get it right again when the code is modified.

I won't lie to you and tell you that most compilers are this good, but
a good compiler (a really good compiler) might NOT do the pointer
arithmetic because of other constraints (tight for registers, e.g.)
that would cause the code to run slower.  See also the paper by Allen
and Johnson in the 1988 SIGPLAN PLDI -- they describe (among other
things) ripping out the pointer arithmetic to discover where vector
operations would be appropriate.  As dependence analysis is put to
better use on scalar machines (helps scheduling, e.g.), you'll find
that the difficulty in analyzing programs will hurt more.

Now, of course, this doesn't make sense if it costs more to run the
optimizer than it does to pay you to write and maintain that
hand-optimized code, but I really doubt it; it's 1990, not 1950.  You
can't assume that all machines have really good optimizing compilers,
but then you don't see too many people trying to port Gnu emacs to a
6502, either -- just treat it as part of the architecture.

So basically, the reasons to avoid pointer arithmetic are:
1) unnecessary
2) error-prone
3) hindrance to some optimizers

Good enough?

David Chase, Menlo Park, CA