Path: utzoo!utgpu!watserv1!watmath!att!att!bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!mjs From: mjs@hpfcso.HP.COM (Marc Sabatella) Newsgroups: comp.lang.misc Subject: Re: REFs or aliases? (was Re: C's sins of commission) Message-ID: <8960021@hpfcso.HP.COM> Date: 31 Oct 90 17:11:27 GMT References: <1990Oct28.165903.9627@newcastle.ac.uk> Organization: Hewlett-Packard, Fort Collins, CO, USA Lines: 38 >> int array[100]; int array[100]; >> int *p; int i; >> extern int *bar(); extern int bar(); >> >> foo () foo () >> { { >> p = bar(); i = bar(); >> *p = 42; array[i] = 42; >> } } > >Yes, but the problem is not whether foo() in isolation is more efficient >but whether the _program_ as a whole is more efficient. In this case, >in order for these two programs to have the same semantics, the base of >array[] must be added into p. Whether this add is done in foo() or in >bar(), it still takes the same time to do. Nonsense. The base of array[] can be "added into p" statically: extern int array[100]; int *bar () { return array+8; } Your points about aliasing are well taken (you've repeated them often enough); I only take issue with the claim that there can *never* be an efficiency advantage to pointers. In an earlier post, I mentioned that the abstract they can provide (virtual machine addresses) are useful to writers of loaders. You replied in mail that you had written a loader using only arrays, which is fine, but it does not change the fact the the abstraction of an actual virtual address can be useful (your array implementation merely substitued integer indices for pointers to achive the same abstraction). Certainly some implementations of pointers can cause aliasing problems in optimizers; no one disputes that. 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).