🚀 go-pugleaf

In article <17114@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
|In article <955@caslon.cs.arizona.edu>, dave@cs.arizona.edu (Dave P.
|Schaumann) writes:
|||In article <1998@gold.gvg.tek.com> shaunc@gold.gvg.tek.com (Shaun
|Case) writes:
||||I know that when you repeatedly access something like
||||
||||foo.a.b.c.d[11].value
||||
||||it is better to declare a (register) pointer, assign it the address
||||of foo.a.b.c.d[11].value, and do manipulations on that, since it
||||is faster.
|||
|||Oh really?  Seems to me that &foo.a.b.c.d[0] is a constant that can be
|||computed *at compile time*.  
|
|Oh really? What if the type of "foo.a.b.c.d" is "struct bar *" and you
|initialize it with:
|    foo.a.b.c.d = (struct bar *) malloc(15 * sizeof(struct bar));
|
|Then neither &foo.a.b.c.d[0] nor &foo.a.b.c.d[11] are compile time
|constants.                        

I think you're wrong.  If the base address of foo is known at compile time,
then &foo.a.b.c.d[0] is simply a constant offset from this base address,
and this constant *must* calculatable at compile time for the compiler to
generate code to access these fields.  And even if the base address of foo is
unknown at compile time, the expression foo.a.b.c.d still represents a known
constant offset from an unknown base address.

If you have foo.baz as the same type as foo.a.b.c.d, accessing foo.baz will
take exactly the same amount of time *at run time* as foo.a.b.c.d, since they
both represent a (different) fixed offset from the same base address.

-- 
		Dave Schaumann		dave@cs.arizona.edu
'Dog Gang'!  Where do they get off calling us the 'Dog Gang'?  I'm beginning to
think the party's over.  I'm beginning to think maybe we don't need a dog.  Or
maybe we need a *new* dog.  Or maybe we need a *cat*! - Amazing Stories