underlying implementation of array and pointer ?

[Stanley Rice]

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 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.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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?

 

[Eric Sosman]

[...]
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.

 

[Stanley Rice]

[...]
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..

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]

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 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.
---------------------------------------------------------------------------­---------------------------------------------------------------------------­------------------------

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

 

[James Kuyper]

--------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.

 

[Stanley Rice]

--------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.

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]

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.