🚀 go-pugleaf

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