Velocity Reviews > Arrays Vs Pointers

# Arrays Vs Pointers

Stefan Ram
Guest
Posts: n/a

 02-07-2012
Ben Bacarisse <(E-Mail Removed)> writes:
>Must "equivalent" mean "can be lexically replaced by"?

No, it's ambigous. It might mean this or something else.

When James writes:

|array[1] takes one less character to type

we are indeed comparing expressions, not their values.

Shao Miller
Guest
Posts: n/a

 02-07-2012
On 2/7/2012 17:54, Stefan Ram wrote:
> Keith Thompson<(E-Mail Removed)> writes:
>> array[1] is *by definition* equivalent to *(array+1).

>
> #include<stdio.h> // printf
>
> int main( void )
> { int b[] ={ 234, 567 }; int * array[ 2 ]={ 0, b };
> printf( "%d\n", array[1] [ 1 ]);
> printf( "%d\n", *(array+1) [ 1 ]);

return 0;
> }

I had to, though it was 100% correct and 0% helpful. Sorry about that.

Ike Naar
Guest
Posts: n/a

 02-07-2012
On 2012-02-07, Stefan Ram <(E-Mail Removed)-berlin.de> wrote:
> Keith Thompson <(E-Mail Removed)> writes:
>>array[1] is *by definition* equivalent to *(array+1).

>
> #include <stdio.h> // printf
>
> int main( void )
> { int b[] ={ 234, 567 }; int * array[ 2 ]={ 0, b };
> printf( "%d\n", array[1] [ 1 ]);
> printf( "%d\n", *(array+1) [ 1 ]); }

You forgot something. Try

printf( "%d\n", ( array[1] ) [ 1 ]);
printf( "%d\n", ( *(array+1) ) [ 1 ]); }

James Kuyper
Guest
Posts: n/a

 02-08-2012
On 02/07/2012 06:12 PM, Stefan Ram wrote:
> Ben Bacarisse <(E-Mail Removed)> writes:
>> Must "equivalent" mean "can be lexically replaced by"?

>
> No, it's ambigous. It might mean this or something else.
>
> When James writes:
>
> |array[1] takes one less character to type
>
> we are indeed comparing expressions, not their values.

Correct - in the context that you brought up, it saves three characters,
all shifted, and not just one.

Keith Thompson
Guest
Posts: n/a

 02-08-2012
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
> Keith Thompson <(E-Mail Removed)> writes:
>>array[1] is *by definition* equivalent to *(array+1).

>
> #include <stdio.h> // printf
>
> int main( void )
> { int b[] ={ 234, 567 }; int * array[ 2 ]={ 0, b };
> printf( "%d\n", array[1] [ 1 ]);
> printf( "%d\n", *(array+1) [ 1 ]); }

Ok, quoting the standard (C99 6.5.2.1p2):

The definition of the subscript operator [] is that E1[E2] is
identical to (*((E1)+(E2))).

It was slightly sloppy of me to omit the parentheses.

(BTW, I find your compressed code layout difficult to read.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson
Guest
Posts: n/a

 02-08-2012
Shao Miller <(E-Mail Removed)> writes:
> On 2/7/2012 17:54, Stefan Ram wrote:
>> Keith Thompson<(E-Mail Removed)> writes:
>>> array[1] is *by definition* equivalent to *(array+1).

>>
>> #include<stdio.h> // printf
>>
>> int main( void )
>> { int b[] ={ 234, 567 }; int * array[ 2 ]={ 0, b };
>> printf( "%d\n", array[1] [ 1 ]);
>> printf( "%d\n", *(array+1) [ 1 ]);

> return 0;
>> }

>
> I had to, though it was 100% correct and 0% helpful. Sorry about that.

C does not require a "return 0;" at the end of main(), as of the current
standard or the one preceding it.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson
Guest
Posts: n/a

 02-08-2012
Ike Naar <(E-Mail Removed)> writes:
> On 2012-02-07, Stefan Ram <(E-Mail Removed)-berlin.de> wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>>>array[1] is *by definition* equivalent to *(array+1).

>>
>> #include <stdio.h> // printf
>>
>> int main( void )
>> { int b[] ={ 234, 567 }; int * array[ 2 ]={ 0, b };
>> printf( "%d\n", array[1] [ 1 ]);
>> printf( "%d\n", *(array+1) [ 1 ]); }

>
> You forgot something. Try
>
> printf( "%d\n", ( array[1] ) [ 1 ]);
> printf( "%d\n", ( *(array+1) ) [ 1 ]); }

I don't believe he "forgot" anything. (In fact, I did.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Shao Miller
Guest
Posts: n/a

 02-08-2012
On 2/7/2012 19:25, Keith Thompson wrote:
> Shao Miller<(E-Mail Removed)> writes:
>> On 2/7/2012 17:54, Stefan Ram wrote:
>>> Keith Thompson<(E-Mail Removed)> writes:
>>>> array[1] is *by definition* equivalent to *(array+1).
>>>
>>> #include<stdio.h> // printf
>>>
>>> int main( void )
>>> { int b[] ={ 234, 567 }; int * array[ 2 ]={ 0, b };
>>> printf( "%d\n", array[1] [ 1 ]);
>>> printf( "%d\n", *(array+1) [ 1 ]);

>> return 0;
>>> }

>>
>> I had to, though it was 100% correct and 0% helpful. Sorry about that.

>
> C does not require a "return 0;" at the end of main(), as of the current
> standard or the one preceding it.
>

I hope you're joking. Mine was a joke. No "requirement" was
claimed. I hoped to add something valuable, just as Mr. Stefan Ram did
for you (other than from Ben's perspective, that is).

John Bode
Guest
Posts: n/a

 02-09-2012
On Feb 7, 3:28*pm, peter <(E-Mail Removed)> wrote:
> Hi all
>
> I am currently exploring the world of pointers and have encounter some
> inconsistent information regarding the best way to reference an
> array: array[1] * OR * **(array +1).
>
> One book says that you should not use the syntax array[1] because
> of performance reason. Another book says that the syntax array[1] is
> only used by FORTRAN programmers who do not understand c pointers. So
> what is the true oh wizards? Does it make a difference?
>
> Thanks Peter

Out of curiosity, which books are these?

FWIW, subscript notation *may* result in a few more instructions at
the assembly level than pointer notation. Here are some examples
compiled with gcc -g -Wa,aldh:

First, indexing with a constant expression:

14:init.c **** y = x[5];
210 .LM5:
211 0025 8B45DC movl -36(%ebp), %eax
212 0028 8945C4 movl %eax, -60(%ebp)
15:init.c **** y = *(x + 5);
214 .LM6:
215 002b 8B45DC movl -36(%ebp), %eax
216 002e 8945C4 movl %eax, -60(%ebp)

No difference; the same number of instructions are generated.

Indexing with an auto variable:

17:init.c **** y = x[z];
218 .LM7:
219 0031 8B45C0 movl -64(%ebp), %eax
220 0034 89C0 movl %eax, %eax
221 0036 8D148500 leal 0(,%eax,4), %edx
221 000000
222 003d 8D45C8 leal -56(%ebp), %eax
223 0040 89C0 movl %eax, %eax
224 0042 8B0402 movl (%edx,%eax), %eax
225 0045 8945C4 movl %eax, -60(%ebp)
18:init.c **** y = *(x + z);
227 .LM8:
228 0048 8B45C0 movl -64(%ebp), %eax
229 004b 8B4485C8 movl -56(%ebp,%eax,4), %eax
230 004f 8945C4 movl %eax, -60(%ebp)

Hmp. Subscripting with a variable results in more instructions
compared to the manual dereference, at least under these
circumnstances (gcc compiler, debugging turned on, no optimization).

This is one specific case, using one specific compiler with one
specific set of compiler settings. If I turn on optimization, those
differences may disappear. Or they may not. It may turn out to be
that using subscript notation *really is* less efficient (or at least
requires more instructions) than manually adding offsets and
dereferencing in most circumstances.

And unless you're failing to meet a *hard* space or performance
requirement AND array accesses are the absolute last place you can
squeeze out those last few bytes and/or cycles *AND* you *know* that
pointer notation will result in fewer/faster instructions, use
subscript notation (x[i]). It's easier to read (especially for
multidimensional array accesses) and it more clearly conveys intent.

When you're thinking about this kind of micro-optimization, you have
to ask yourself the following questions:

1. How many times am I executing this operation? Do I do it once
over the lifetime of the program (in which case any gains are down in
the noise), or do I repeat the operation hundreds or thousands (or
more) times (in which case the gains are measurable)?

2. Have I *measured* the performance difference between the two
versions? Under a variety of conditions?

3. Are these differences consistent across different compilers?
Would leaving the code alone and simply switching to a different/
better compiler buy me the performance I need?

4. What is the tradeoff in terms of readability/maintainability?
Would I rather debug code that reads

x = y[i][j++][++k];

or

x = *(*(*(y + i) + j++) + ++k);

Both hurt to look at, but IMO the first hurts less. YMMV.

Philip Lantz
Guest
Posts: n/a

 02-09-2012
John Bode wrote:
> On Feb 7, 3:28*pm, peter wrote:
> > I am currently exploring the world of pointers and have encounter
> > some inconsistent information regarding the best way to reference
> > an array: array[1] * OR * **(array +1).
> >
> > One book says that you should not use the syntax array[1] because
> > of performance reason.

>
> FWIW, subscript notation *may* result in a few more instructions at
> the assembly level than pointer notation. Here are some examples
> compiled with gcc -g -Wa,aldh:
>

[examples snipped]
>
> Hmp. Subscripting with a variable results in more instructions
> compared to the manual dereference, at least under these
> circumnstances (gcc compiler, debugging turned on, no optimization).

Looking at the code generated with no optimization is pointless--if you
care about performance, you need to turn on optimizations; it's as
simple as that. GCC generates really horrible code with optimizations
off, as exemplified by the *two* "mov eax, eax" instructions in your
sample code.

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post cerr C Programming 12 04-07-2011 11:17 PM Francesco C++ 2 11-06-2009 09:04 AM Philipp Java 21 01-20-2009 08:33 AM ketema@gmail.com C Programming 1 03-28-2005 03:51 AM kelvSYC C Programming 2 09-26-2003 06:52 AM

Advertisments