🚀 go-pugleaf

>> Jim, you've made a blanket assertion that arrays are as efficient as
>> pointers. I've proven you wrong. Give up.
>
>You have not even posted _one_ counter-example.

Perhaps not, but *I* have.

You just chose to brush it off by saying, "oh well nobody writes code like that
anyhow, or at least they shouldn't".

For those with short memories: if you compute "pointer = base + offset" in
one procedure, and pass the pointer to another procedure, then there is only
one addition in the two procedures.  With arrays, unless you have
interprocedural flow information (especially hard between source files, even
more so if one routine is in a library), you'll have to perform the addition
twice - once in each procedure.  Extend this to several procedures, and
pointers win by a wider margin (still only one addition required).

Or you could pass the array element by reference, but this requires relaxing of
type rules if you want to actually access other members of the array in the
called procedure.  It seems to me this relaxation, if allowed by the language,
would tend to weaken non-aliasing assumptions as well, or would at least place
heavier burdens on the programmer to avoid aliasing.

I find this argument kind of pointless though; I rarely care about one integer
addition.  In fact, on some processors, indirect addressing is just as fast
with or without an index.  I use pointers because the abstraction they provide
is indeed useful to me.  I use arrays relatively rarely, as that abstraction is
not normally as useful to me.  As you may have guessed, I do mainly systems
programming, not mathematical.  I will indeed grant that I wish the compiler
would recognize that my application of dynamic relocation records cannot affect
the relocation records themselves.  But don't take away my pointers; just give
me the means to specify either type of declaration.

--------------
Marc Sabatella (marc@hpmonk.fc.hp.com)
Disclaimers:
	2 + 2 = 3, for suitably small values of 2
	Bill and Dave may not always agree with me