Path: utzoo!attcan!uunet!decwrl!mcnc!uvaarpa!murdoch!astsun9.astro.Virginia.EDU!gl8f
From: gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX (was C's sins... and others)
Message-ID: <1990Oct28.015733.9181@murdoch.acc.Virginia.EDU>
Date: 28 Oct 90 01:57:33 GMT
References: <26726@megaron.cs.arizona.edu>
Sender: news@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 31

In article <26726@megaron.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>In article  <3656@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>
>]Of course, pointers and one dimensional arrays - in spite of their
>]similarity - are indeed different.  For one thing: arrays are bounded.
>
>You know, Jim, it doesn't help your argument any when you keep
>bringing up the same points long after they have been discredited.
>Pointers are bounded just like array indexes.

Actually, it just shows that we're talking past each other most of the
time. Here's a practical example where the boundedness of array
references allows you to easily generate better code:

     a[i] = b[i] + c[i]             *a = *b + *c;
     d[i] = b[i] / 2.               *d = *b / 2.

For the array version, the compiler can check to see if a and b
overlap, and if not it doesn't have to load b[i] twice. For the
pointer version, the compiler has to figure out what a, b, c, and d
point at, if it even bothers at all.

>  Yes, most
>implementations of C don't check the bounds, but that is because in
>the definition of the C language, run-time errors are generally
>defined to produced undefined results.

I'm not worried about run-time errors, I'm worried about run-time
efficiency. Some languages are hard to optimize. When C programers do
strength reduction by hand on array accesses, they create an
optimization mess.