Asp Forum - underlying implementation of array and pointer ?

Stanley Rice

9/8/2011 12:40:00 AM

I am confused of the underlying implementation of array indexing and
pointer arithmetic.

In comp.lang.c FAQ list · Question 6.3, it states that
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
A reference to an object of type array-of-T which appears in an
expression decays (with three exceptions) into a pointer to its first
element; the type of the resultant pointer is pointer-to-T.
That is, whenever an array appears in an expression, the compiler
implicitly generates a pointer to the array's first element, just as
if the programmer had written &a[0]. (The exceptions are when the
array is the operand of a sizeof or & operator, or is a string literal
initializer for a character array. [footnote] See questions 6.23,
6.12, and 1.32, respectively.)

As a consequence of this definition, and in spite of the fact that the
underlying arrays and pointers are quite different, the compiler
doesn't apply the array subscripting operator [] that differently to
arrays and pointers, after all.[footnote] Given an array a and pointer
p, an expression of the form a[i] causes the array to decay into a
pointer, following the rule above, and then to be subscripted just as
would be a pointer variable in the expression p[i].
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Following the above roles, I suppose that using pointer is more
efficient(compile efficiency) than using array. To prove my opinion, I
wrote some code:

--------test.c-------
#include <stdio.h>
int main() {
const char p[] = "hello"; // (1)
//const char *p = "hello"; // (2)

//Either printf("%d\n", *(p + 2)); is ok, the resulting time
consumption is almost the same.
printf("%c\n", p[2]);
printf("%c\n", p[2]);
.......//repeat the above statement for 70,000 times.
return 0;
}

In my ubuntu, I use "time gcc test.c", it nearly takes me 20 seconds
to compile it.
But when I comment the (1) statement, uncomment the (2) statement,
guess what happens? Will it take fewer time than the previous test as
it is using pointers. However, it takes nearly 25-27 seconds.

Will array first decay to a pointer to the first element of the array
when the array is referenced in an expression? But, why it looks more
efficient than using pointer directly?

6 Answers

Eric Sosman

9/8/2011 2:20:00 AM

On 9/7/2011 8:39 PM, Stanley Rice wrote:
>[...]
> In my ubuntu, I use "time gcc test.c", it nearly takes me 20 seconds
> to compile it.
> But when I comment the (1) statement, uncomment the (2) statement,
> guess what happens? Will it take fewer time than the previous test as
> it is using pointers. However, it takes nearly 25-27 seconds.

The time taken to translate a piece of code has little if
anything to do with the time taken to execute it. Consider the
two code snippets

int x = 0;
and
int x = (1 - 2 + 3 - 4 + 5 - 6 + 7 - 8 + 9 - 10 + 11) / 12;

Both have exactly the same effect, and will (very probably) generate
identical code. But the second requires the compiler to convert and
validity-check a dozen numbers to the first's one, and do a whole lot
of arithmetic on them into the bargain. Same outcome, quite probably
the same run-time code, but different "degrees of difficulty" in
translation.

Usually, C programmers are more concerned with execution time than
with compilation time: They are, usually, quite happy if the compiler
spends an extra five seconds concocting a clever optimization that
shaves five microseconds off the code's running time, because they
expect to run the code five billion times and recoup the investment.
(Or they're of the non-thinking variety that think "optimized is always
better," and don't count the cost.) Some languages put more emphasis
on quicker translation, to shorten the edit-compile-run-debug cycle.
There's no reason a C implementation couldn't favor compile time over
execution time (gcc offers an approximate sliding scale of -O0 to -O3),
but historically C tools have put a premium on run-time performance as
opposed to compile-time performance. It's just a mind-set, if you like.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Stanley Rice

9/8/2011 8:23:00 AM

On Sep 8, 10:19 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 9/7/2011 8:39 PM, Stanley Rice wrote:
>
> >[...]
> > In my ubuntu, I use "time gcc test.c", it nearly takes me 20 seconds
> > to compile it.
> > But when I comment the (1) statement, uncomment the (2) statement,
> > guess what happens? Will it take fewer time than the previous test as
> > it is using pointers. However, it takes nearly 25-27 seconds.
>
> The time taken to translate a piece of code has little if
> anything to do with the time taken to execute it. Consider the
> two code snippets
>
> int x = 0;
> and
> int x = (1 - 2 + 3 - 4 + 5 - 6 + 7 - 8 + 9 - 10 + 11) / 12;
>
> Both have exactly the same effect, and will (very probably) generate
> identical code. But the second requires the compiler to convert and
> validity-check a dozen numbers to the first's one, and do a whole lot
> of arithmetic on them into the bargain. Same outcome, quite probably
> the same run-time code, but different "degrees of difficulty" in
> translation.
>
> Usually, C programmers are more concerned with execution time than
> with compilation time: They are, usually, quite happy if the compiler
> spends an extra five seconds concocting a clever optimization that
> shaves five microseconds off the code's running time, because they
> expect to run the code five billion times and recoup the investment.
> (Or they're of the non-thinking variety that think "optimized is always
> better," and don't count the cost.) Some languages put more emphasis
> on quicker translation, to shorten the edit-compile-run-debug cycle.
> There's no reason a C implementation couldn't favor compile time over
> execution time (gcc offers an approximate sliding scale of -O0 to -O3),
> but historically C tools have put a premium on run-time performance as
> opposed to compile-time performance. It's just a mind-set, if you like.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

Thanks for your replying. I agree with your opinion and I also compile
my program with -O3 argument when I want to release it. Most of the C
programmer concern running efficiency more than the compiling
efficiency. But I am sorry that it's not my current question. I wander
if or why the compiler takes less time to compile the reference with
array index rather than pointer arithmetic.

Anyway, thank again for replying.

Nick Keighley

9/8/2011 9:44:00 AM

On Sep 8, 1:39 am, Stanley Rice <hecong...@gmail.com> wrote:
> I am confused of the underlying implementation of array indexing and
> pointer arithmetic.
>
> In comp.lang.c FAQ list · Question 6.3, it states that
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> A reference to an object of type array-of-T which appears in an
> expression decays (with three exceptions) into a pointer to its first
> element; the type of the resultant pointer is pointer-to-T.
> That is, whenever an array appears in an expression, the compiler
> implicitly generates a pointer to the array's first element, just as
> if the programmer had written &a[0]. (The exceptions are when the
> array is the operand of a sizeof or & operator, or is a string literal
> initializer for a character array. [footnote] See questions 6.23,
> 6.12, and 1.32, respectively.)
>
> As a consequence of this definition, and in spite of the fact that the
> underlying arrays and pointers are quite different, the compiler
> doesn't apply the array subscripting operator [] that differently to
> arrays and pointers, after all.[footnote] Given an array a and pointer
> p, an expression of the form a[i] causes the array to decay into a
> pointer, following the rule above, and then to be subscripted just as
> would be a pointer variable in the expression p[i].
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Following the above roles, I suppose that using pointer is more
> efficient(compile efficiency) than using array. To prove my opinion, I
> wrote some code:
>
> --------test.c-------
> #include <stdio.h>
> int main() {
> const char p[] = "hello"; // (1)
> //const char *p = "hello"; // (2)
>
> //Either printf("%d\n", *(p + 2)); is ok, the resulting time
> consumption is almost the same.
> printf("%c\n", p[2]);
> printf("%c\n", p[2]);
> .......//repeat the above statement for 70,000 times.
> return 0;
>
> }
>
> In my ubuntu, I use "time gcc test.c", it nearly takes me 20 seconds
> to compile it.

sounds rather a long time

> But when I comment the (1) statement, uncomment the (2) statement,
> guess what happens? Will it take fewer time than the previous test as
> it is using pointers. However, it takes nearly 25-27 seconds.
>
> Will array first decay to a pointer to the first element of the array
> when the array is referenced in an expression? But, why it looks more
> efficient than using pointer directly?

James Kuyper

9/8/2011 12:49:00 PM

On 09/08/2011 05:44 AM, Nick Keighley wrote:
> On Sep 8, 1:39ï¿½am, Stanley Rice <hecong...@gmail.com> wrote:
....
>> --------test.c-------
>> #include <stdio.h>
>> int main() {
>> ï¿½ ï¿½const char p[] = "hello"; ï¿½ ï¿½ ï¿½// ï¿½(1)
>> ï¿½ ï¿½//const char *p = "hello"; ï¿½ ï¿½// ï¿½ (2)
>>
>> ï¿½ ï¿½//Either printf("%d\n", *(p + 2)); is ok, the resulting time
>> consumption is almost the same.
>> ï¿½ ï¿½printf("%c\n", p[2]);
>> ï¿½ ï¿½printf("%c\n", p[2]);
>> ï¿½ ï¿½.......//repeat the above statement for 70,000 times.
>> ï¿½ ï¿½return 0;
>>
>> }
>>
>> In my ubuntu, I use "time gcc test.c", it nearly takes me 20 seconds
>> to compile it.
>
> sounds rather a long time

His program contains 70,002 identical printf() statements, in a single
translation unit.
--
James Kuyper

Stanley Rice

9/8/2011 2:35:00 PM

On Sep 8, 8:49 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 09/08/2011 05:44 AM, Nick Keighley wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 8, 1:39 am, Stanley Rice <hecong...@gmail.com> wrote:
> ...
> >> --------test.c-------
> >> #include <stdio.h>
> >> int main() {
> >> const char p[] = "hello"; // (1)
> >> //const char *p = "hello"; // (2)
>
> >> //Either printf("%d\n", *(p + 2)); is ok, the resulting time
> >> consumption is almost the same.
> >> printf("%c\n", p[2]);
> >> printf("%c\n", p[2]);
> >> .......//repeat the above statement for 70,000 times.
> >> return 0;
>
> >> }
>
> >> In my ubuntu, I use "time gcc test.c", it nearly takes me 20 seconds
> >> to compile it.
>
> > sounds rather a long time
>
> His program contains 70,002 identical printf() statements, in a single
> translation unit.
> --
> James Kuyper

I am not trying to run the program, instead, I just compiled it and
then found the difference.
Do you have some conclusion?

James Kuyper

9/8/2011 3:32:00 PM

On 09/08/2011 10:35 AM, Stanley Rice wrote:
> On Sep 8, 8:49 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 09/08/2011 05:44 AM, Nick Keighley wrote:
....
>>> On Sep 8, 1:39 am, Stanley Rice <hecong...@gmail.com> wrote:
....
>>>> In my ubuntu, I use "time gcc test.c", it nearly takes me 20 seconds
>>>> to compile it.
>>
>>> sounds rather a long time
>>
>> His program contains 70,002 identical printf() statements, in a single
>> translation unit.
>> --
>> James Kuyper
>
> I am not trying to run the program, instead, I just compiled it and
> then found the difference.

I was just pointing out that 20 seconds might not be an unusually long
time to process such a large program.

> Do you have some conclusion?

Yes. You're worrying far too much about compile time. The time that it
takes you to write the code, and the time that it takes someone else to
read and understand it, are both far more important than the time it
takes to compile it. You should concentrate on writing the code so that
it clearly expresses your intent and is easy to maintain.

comp.lang.c

underlying implementation of array and pointer ?

Stanley Rice

Eric Sosman

Stanley Rice

Nick Keighley

James Kuyper

Stanley Rice

James Kuyper

x Login to ForumsZone