NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/c/12920

Internet Message Format | 1992-08-29 | 1.5 KB

Path: sparky!uunet!stanford.edu!rutgers!princeton!mccc!pjh
From: [e-mail] (Pete Holsberg)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Message-ID: <[e-mail]>
Date: 28 Aug 92 16:37:24 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: The College On The Other Side Of Route One
Lines: 31

In article <[e-mail]> [e-mail] (Greg Henderson) writes:
=Well one reason that pops to mind is the nice ability to use a pointer
=to traverse an array more efficently than the 'normal' way.  For ex...
=
=You could do this normally:
={
=    int a[1000], i;
=
=    for ( i=0; i<1000; i++ )
=    a[i] = get_some_arbitrary_value();
=}
=
=Or you could do this w/ a pointer:
={
=    int a[1000], *_i;
=
=    for (_i=a;  _i<a+1000; _i++ )
=    *_i = get_some_arbitrary_value();
=}
=
=These two pieces of code do the exact same thing, but if you are
=worried about low-level efficiency the second version is a little
=tighter, as each reference to the array value in the pointer version
=requires less work to come up w/ that address.

Isn't that a function of the compiler? In fact, let me ask why don't we
have compilers that produce the most efficient code even when array
notation is used? Is it that they would be too slow? I recall a FORTRAN
compiler for a 16-bit digital computer used in a hybrid computer system
back in the 60s that produced wonderful code, but took a very very long
time to do it.