Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: REFs or aliases? (was Re: C's sins of commission)
Message-ID: <4667@lanl.gov>
Date: 1 Nov 90 19:13:01 GMT
References: <8960021@hpfcso.HP.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 45

From article <8960021@hpfcso.HP.COM>, by mjs@hpfcso.HP.COM (Marc Sabatella):
> [...]
> Nonsense.  The base of array[] can be "added into p" statically:
> 
> 	extern int array[100];
> 
>       int *bar ()
>       {
>               return array+8;
>       }

So can the array base.  Array[8] is a static location.  To be sure,
your _very_ contrived example prevents a compiler from detecting this
without interprocedural analysis.  But, how many codes do you have
that really are structured this way?  Do you recommend this structure?
Most importantly: do you really think that you have proved you point
if restructuring the code will still allow arrays to be as fast as
your pointers?

> [...]
> I only take issue with the claim that there can *never* be an efficiency
> advantage to pointers.  [...]

I still stand by that claim.  A contrived example in which pointers
only provide a savings if a procedure is called in order to return a
static offset isn't really a very good counter-example.  If it's a
static offset, why don't you inline it (as a macro even - if you insist
on the modularity of making a call here)?  If it's not a static offset,
then, as I've said before, it doesn't really save anyway.

> [...]                              This does not change the inherent usefulness
> of the abstraction, or the fact that there are cases where pointers can give
> you a win (especially in an implementation with more restricted aliasing).

It is _that_ claim that I've repeatedly challenged people to prove.
I want an example of a case where pointers really constitute a gain
over the alternatives.  Your only answer so far has been to provide
a code which is structured upside-down.  In other words, the
pointers aren't needed for the functionality but to make up for bad
programming style.  Perhaps that's enough of a reason to include
pointers - but I don't think so.  Especially since pointers
encourange bad style as often (or more often) than they make up for
it.

J. Giles