Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!seismo.gps.caltech.edu!bruce
From: bruce@seismo.gps.caltech.edu (Bruce Worden)
Newsgroups: comp.lang.c
Subject: Re: p[1] vs. *(p+1)
Message-ID: <1990Aug31.190103.15043@laguna.ccsf.caltech.edu>
Date: 31 Aug 90 19:01:03 GMT
References: <1881@jura.tcom.stc.co.uk> <3603@goanna.cs.rmit.oz.au> <1990Aug24.064203.20942@icc.com> <26D952F5.4E44@tct.uucp> <1745@io.UUCP>
Sender: bruce@seismo.gps.caltech.edu (Bruce Worden)
Organization: California Institute of Technology, CA
Lines: 25

In article <1745@io.UUCP> prs@eng.ileaf.com (Paul Schmidt) writes:

> [ material deleted ]
>So, that means that the compiler must know the size of the elements of
>array p, and that *(p+1) does not add 1 to p, but instead adds
>sizeof(array_element_type) to p?

Yes.  It is very important to understand that point if you are going to be
shuffling pointers around.

>I must confess that I use p[1] in these cases, and count on the compiler
>to optimize for me.

In a simple case like p[1] the compiler may well optimize, but then it isn't 
a particularly time consuming operation.  Though we are getting bit off of the 
original subject, in the case of a loop, the performance difference between 
   *p1++ = *a1++ * *b1++;  
and 
    p2[i] = a2[i] * b2[i]; 
can be significant.  The performance strongly depends on the compiler and, 
in the case of floating-point operands, how well the compiler exploits the 
features available in the hardware.
--------------------------------------------------------------------------
C. Bruce Worden                            bruce@seismo.gps.caltech.edu
252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125