Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Relationship between C and C++
Message-ID: <14295@lambda.UUCP>
Date: 27 Mar 90 21:26:32 GMT
References: <1990Mar26.181444.11727@maths.nott.ac.uk>
Lines: 98

From article <1990Mar26.181444.11727@maths.nott.ac.uk>, by anw@maths.nott.ac.uk (Dr A. N. Walker):
> In article <14286@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>> [...]
>>						    Two different arrays
>>are two different objects.  Period.
> 
> 	So, there are some occasions where a compiler can be sure that
> a[i] and b[j] are different objects;

Yes - the 'some occasions' happens to be nearly always: because such
array aliasing is _illegal_.  To be sure, few compilers provide an
option to detect such aliasing.  Such a run-time test would be simple
and would cost about the same as array bounds checking.  The fact that
few compilers provide it indicates that the error is extremely rare.

> [...]                                 and it's relatively harder to be
> sure that pa, pb point into different objects.

That's not the point (so to speak).  The fact is, it's _legal_ for
the two pointers to be aliased.  So, even if you _could_ detect when
they were aliased and when they were not, what would you do with the
information?  Compile all your code both ways (and if there are more
than two pointer args - the number of different aliasing combinations
increases combinatorially) and make a run time decision which version
to use?  Not at all cost effective.

Further, in view of the fact that array args are seldom aliased anyway
(see above about the infrequency of such a thing in languages where
aliasing is not allowed), C must make a pessimizing assumption about
its procedure args in order to support a rarely needed feature.

> [...]                                           On the other hand, if
> a and b are parameters, they *may* (in C and many other languages) be
> the same array, and EXACT... (sorry) exactly the same problems arise.

If a and b are array parameters, then (in most languages) they
*may*not* be the same array (at least, not if the procedure
assigns to either of them).  So, in these languages, the same
problems do not arise.  This is exactly the nature of the weakness
in C that I've been complaining about.

>>[...]				 But, the implementor can optimize array
>>usage with a clear conscience - after all, only illegal programs get
>>broken. [...]
> 
> 	The question was about C pointer arithmetic.

Nice try.  But the statement that I responded to was your claim that
arrays and pointers were the same.  They aren't.  C confuses the issue
by not having a mechanism to pass arrays to procedures - it converts
them to pointers.  I made the claim that C's pointers and arrays were
the same a long time ago and the C community came down on me like a
ton of bricks.  Since then I've learned to be more careful with my
terms.  C has global arrays, local arrays, and something in between
with 'file' scope - C does not have array arguments to procedures.

> [...]                                             In C, legal programs
> also get broken if potentially aliassed arrays are optimised as though
> they are not aliassed.

Exactly!  C must pessimize the code in ways that other languages needn't.

> [...]
>>[I know - still beating the same dead horse.  This issue NEVER seems to
>>go away.]
> 
> 	Well, it helps if we are all looking at the same horse.  The point
> at issue is not whether C or Fortran or Pascal or ... has better arrays, or
> better rules about side-effects, but whether pointer arithmetic should be
> considered harmful.

In other words, you're considering a language design issue involving the
use of pointers.  In C, it's difficult to decouple pointer arithmetic from
array manipulation since the language itself confuses the two.  It is
difficult for me to imagine _any_ language in which questions about
pointers can be decoupled from the issue of aliasing.  As with any other
language design issue, comparison to other languages is a prefectly
appropriate thing to do.

> [...]                 Unless someone has a more convincing example than we
> have seen so far, the answer is no.  You should use it when it is right to
> do so, and not otherwise. [:-)]

Oh, I agree.  You should avoid pointer use of any kind unless the
benefits outweigh the penalty.  The penalty is less readible code
that is poorly optimized because of aliasing.  But, since you mention
it: what context do you think is appropriate for the use of pointer
arithmetic?  Bear in mind that, except for aliasing and bounds checking
differences, pointer arithmetic is semantically _identical_ to array
indexing on a single dimensioned array.  Since pointers are _less_
desireable because of aliasing and bounds checking differences, what
application do you claim an advantage for pointer use?  I can think
of only one - and I suspect it won't be the one you propose - I'll
wait and see.

(All comments about beating dead horses still apply.)

J. Giles