Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!ig!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: JLG's flogging of horses (was Re: Relationship between C and C++)
Message-ID: <20026@megaron.cs.arizona.edu>
Date: 9 Apr 90 23:03:58 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 60

In article  <14305@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>From article <19844@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
>> [...]
>> Trivial.  Let A be an array of type t, pA be a pointer of type t, and
>> i be an integer.  All pointers and arrays are stored as a triple <base
>> address, index, max_index> where index = 0 for arrays.
>> [... rules of bounds checking, assignment, etc. ...]
>
>   t A [N] [M];    /* 2d array of type t */
>   t *pA;
>   ...
>   pA = A;
>
>...  So, the
>above assignment should have been:
>
>   pA = (t *) A;
>
>Now, what bounds are associated with pA under your scheme?  N clearly
>doesn't make sense.  But should the bound be M or N*M?  Whichever you
>pick, I'll (sooner or later) want it to be the other.

This is a non-problem.  The expressions "A" returns a triple <address
of A, 0, N*M> and the case does not change that.  If you want the
bound to be M you write pA = A[0] (as someone else has already pointed
out.  I think you are confusing the dynamic triples with the static
types.  The two are unrelated except that the size must be known to
interpret the indexes.  Someone else suggested using three addresses
instead of an address and two indexes, and this makes the triples
even more independent of the types.

>... If your algorithm is manipulating
>an array, it remains more readible, verifyable, and maintainable if
>all the array references use the array syntax.

I'm not sure whether you recognize that the above statement is one of
the basic sources of disagreement.  I claim that the above statement
is not true in general.  In fact I claim the following: (1)
readability is largely a subjective notion, and there will always be
some people who find pointer arithmetic to be more readable and some
who find indexes to be more readable.  (2) verifyability is a tenuous
notion at the present time, and any method of verification that can
not handle pointer arithmetic is inadequate.  (3) maintainability is
independent of which method of array access is used.

>Not only that, the array
>syntax allows your compiler greater freedom in optimization - so your
>code often runs _faster_ as well.  Unfortunately, C performs the array
>to pointer conversion implicitly in the procedure call mechanism.

This is another statement that is wrong.  Compilers can optimize
pointer arithmetic to the same extent as array indexing.  It is
true that the optimization of pointer arithmetic is more difficult,
but a good enough compiler can detect all possible aliases by global
control flow analysis, even with seperate compilation.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman