Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #16866 > unrolled thread

Arrays Vs Pointers

Back to article view | Back to comp.lang.c

Contents

  Arrays Vs Pointers peter <pc722@nospam.mail.com.br> - 2012-02-07 21:28 +0000
    Re: Arrays Vs Pointers William Ahern <william@wilbur.25thandClement.com> - 2012-02-07 13:50 -0800
    Re: Arrays Vs Pointers James Kuyper <jameskuyper@verizon.net> - 2012-02-07 17:13 -0500
    Re: Arrays Vs Pointers Stephen Sprunk <stephen@sprunk.org> - 2012-02-07 16:38 -0600
      Re: Arrays Vs Pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-07 23:09 +0000
    Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-07 14:41 -0800
      Re: Arrays Vs Pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-07 23:07 +0000
        Re: Arrays Vs Pointers James Kuyper <jameskuyper@verizon.net> - 2012-02-07 19:14 -0500
      Re: Arrays Vs Pointers Shao Miller <sha0.miller@gmail.com> - 2012-02-07 18:21 -0500
        Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-07 16:25 -0800
          Re: Arrays Vs Pointers Shao Miller <sha0.miller@gmail.com> - 2012-02-07 20:31 -0500
      Re: Arrays Vs Pointers Ike Naar <ike@sverige.freeshell.org> - 2012-02-07 23:36 +0000
        Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-07 16:26 -0800
      Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-07 16:24 -0800
    Re: Arrays Vs Pointers Paul N <gw7rib@aol.com> - 2012-02-07 14:55 -0800
    Re: Arrays Vs Pointers Shao Miller <sha0.miller@gmail.com> - 2012-02-07 18:11 -0500
    Re: Arrays Vs Pointers John Bode <jfbode1029@gmail.com> - 2012-02-08 16:06 -0800
      Re: Arrays Vs Pointers Philip Lantz <prl@canterey.us> - 2012-02-08 23:25 -0800
        Re: Arrays Vs Pointers John Bode <jfbode1029@gmail.com> - 2012-02-09 05:34 -0800
          Re: Arrays Vs Pointers Philip Lantz <prl@canterey.us> - 2012-02-10 01:04 -0800
    Re: Arrays Vs Pointers Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-09 00:20 -0800
      Re: Arrays Vs Pointers 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-09 23:42 -0800
      Re: Arrays Vs Pointers gwowen <gwowen@gmail.com> - 2012-02-10 01:20 -0800
      Re: Arrays Vs Pointers David Thompson <dave.thompson2@verizon.net> - 2012-02-18 23:12 -0500
        Re: Arrays Vs Pointers Kaz Kylheku <kaz@kylheku.com> - 2012-02-19 05:53 +0000
          Re: Arrays Vs Pointers Markus Wichmann <nullplan@gmx.net> - 2012-02-19 18:54 +0100
            Re: Arrays Vs Pointers Willem <willem@toad.stack.nl> - 2012-02-19 18:51 +0000
            Re: Arrays Vs Pointers "io_x" <a@b.c.invalid> - 2012-02-19 21:29 +0100
            Re: Arrays Vs Pointers Markus Wichmann <nullplan@gmx.net> - 2012-02-20 11:24 +0100
            Re: Arrays Vs Pointers gwowen <gwowen@gmail.com> - 2012-02-21 01:51 -0800
    Re: Arrays Vs Pointers Willem <willem@toad.stack.nl> - 2012-02-19 12:32 +0000
      Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-19 12:21 -0800
        Re: Arrays Vs Pointers Willem <willem@toad.stack.nl> - 2012-02-19 21:00 +0000
          Re: Arrays Vs Pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-19 21:42 +0000
        Re: Arrays Vs Pointers pete <pfiland@mindspring.com> - 2012-02-20 17:32 -0500
          Re: Arrays Vs Pointers James Kuyper <jameskuyper@verizon.net> - 2012-02-20 17:56 -0500
          Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-20 15:19 -0800
            Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-20 16:35 -0800
              Re: Arrays Vs Pointers pete <pfiland@mindspring.com> - 2012-02-20 22:53 -0500
                Re: Arrays Vs Pointers Keith Thompson <kst-u@mib.org> - 2012-02-20 21:16 -0800
              Re: Arrays Vs Pointers Richard Sanders <lnr729@gmail.com> - 2012-02-21 00:26 -0800
                Re: Arrays Vs Pointers pete <pfiland@mindspring.com> - 2012-02-21 11:46 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#16964

On Feb 7, 9:28 pm, peter <pc...@nospam.mail.com.br> 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).

which is shortest and clearest? I'm much more of a fan of array
notation. Simple, clear and less typing. Modern compilers (anything in
the last 20 years or so) generate identical code anyway.

The only time I tend to use pointers is say picking a comms packet
apart.

   pkt_ptr = &packet [0];
   type = *pkt_ptr++;
   length = (*pkt_ptr) * 256 + *pkt_ptr;
   pkt_ptr += 2;

Each time you read a byte you advance the pointer you don't have to
keep track and count bytes yourself. So is the CRC field in byte 21 or
byte 22? Well it depends if the Qualifier option was selected.

> One book says that you should not use the syntax array[1] because
> of performance reason.

bad reason. It likely makes no difference.

1. write clear, correct code
2. test it thoughly
3. if its too slow make it faster

step 3 is not necessary far more often tahn many people imagine.
People often *start* at step 3. "wow that's /really/ fast, all you
have to do now is make it give the right answer!"

> Another book says that the syntax array[1] is
> only used by FORTRAN programmers who do not understand c pointers.

burn the book.

blacklist the place you bought it

tell your friends

hell, tell us! What was this book?

> So
> what is the true oh wizards? Does it make a difference?

WRITE SIMPLE CODE

[toc] | [prev] | [next] | [standalone]

#17041

在 2012年2月9日星期四UTC+8下午4时20分23秒，Nick Keighley写道：
> On Feb 7, 9: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).
> 
> which is shortest and clearest? I'm much more of a fan of array
> notation. Simple, clear and less typing. Modern compilers (anything in
> the last 20 years or so) generate identical code anyway.
> 
> The only time I tend to use pointers is say picking a comms packet
> apart.
> 
>    pkt_ptr = &packet [0];
>    type = *pkt_ptr++;
>    length = (*pkt_ptr) * 256 + *pkt_ptr;
>    pkt_ptr += 2;
> 
> Each time you read a byte you advance the pointer you don't have to
> keep track and count bytes yourself. So is the CRC field in byte 21 or
> byte 22? Well it depends if the Qualifier option was selected.
> 
> > One book says that you should not use the syntax array[1] because
> > of performance reason.
> 
> bad reason. It likely makes no difference.
> 
> 1. write clear, correct code
> 2. test it thoughly
> 3. if its too slow make it faster
> 
> step 3 is not necessary far more often tahn many people imagine.
> People often *start* at step 3. "wow that's /really/ fast, all you
> have to do now is make it give the right answer!"
> 
> > Another book says that the syntax array[1] is
> > only used by FORTRAN programmers who do not understand c pointers.
> 
> burn the book.
> 
> blacklist the place you bought it
>
Don't burn the book. That is not the way to learn black magics in manny
books in the sophomore or above levels. 
 
 
> tell your friends
> 
> hell, tell us! What was this book?
> 
> > So
> > what is the true oh wizards? Does it make a difference?
> 
> WRITE SIMPLE CODE

Learn to write  more black spells in the graduate school levels. 
Don't be so innocent like a child in the elementary school.

[toc] | [prev] | [next] | [standalone]

#17045

On Feb 9, 8:20 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:

>> So
>> what is the true oh wizards? Does it make a difference?
>
> WRITE SIMPLE CODE

Amen.

"Programs must be written for people to read, and only incidentally
for machines to execute." -- Abelson & Sussman, Structure and
Interpretation of Computer Programs

[toc] | [prev] | [next] | [standalone]

#17592

On Thu, 9 Feb 2012 00:20:23 -0800 (PST), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

> On Feb 7, 9:28 pm, peter <pc...@nospam.mail.com.br> wrote:
<snip>
> The only time I tend to use pointers is say picking a comms packet
> apart.
> 
>    pkt_ptr = &packet [0];
>    type = *pkt_ptr++;
>    length = (*pkt_ptr) * 256 + *pkt_ptr;
>    pkt_ptr += 2;
> 
I really hope you meant 
  length = pkt_ptr[0] * 256 + pkt_ptr[1]; pkt_ptr += 2;
or one of the several equivalent vairants. Or possibly 
  len = *pkt_ptr++;
  len = len * 256 + *pkt_ptr++;
or again variants, but critically with a sequence point somehow.

> Each time you read a byte you advance the pointer you don't have to
> keep track and count bytes yourself. So is the CRC field in byte 21 or
> byte 22? Well it depends if the Qualifier option was selected.
> 
That works with an index variable also.
  int i = 0; // or unsigned or size_t
  type = pkt[i++];
  len = pkt[i] * 256 + pkt[i+1]; i += 2;
or other variants similarly.

I've even been known to write
  len = pkt[i+0] * 256 + pkt[i+1; i += 2;
to show the symmetry, and count on the compiler optimizing +0.

And FW(L)IW it's theoretically safer to check
  if( i + len > size_read ) /* invalid */
than 
  if( ptr + len > buf + size_read ) /* invalid */
since merely forming an invalid pointer, even without dereferencing
it, is Undefined Behavior, while an out-of-expected-range integer is
not, except for signed overflow which is often easier to avoid.

<snip rest>

[toc] | [prev] | [next] | [standalone]

#17597

On 2012-02-19, David Thompson <dave.thompson2@verizon.net> wrote:
> On Thu, 9 Feb 2012 00:20:23 -0800 (PST), Nick Keighley
><nick_keighley_nospam@hotmail.com> wrote:
>
>> On Feb 7, 9:28 pm, peter <pc...@nospam.mail.com.br> wrote:
><snip>
>> The only time I tend to use pointers is say picking a comms packet
>> apart.
>> 
>>    pkt_ptr = &packet [0];
>>    type = *pkt_ptr++;
>>    length = (*pkt_ptr) * 256 + *pkt_ptr;
>>    pkt_ptr += 2;
>> 
> I really hope you meant 
>   length = pkt_ptr[0] * 256 + pkt_ptr[1]; pkt_ptr += 2;
> or one of the several equivalent vairants. Or possibly 
>   len = *pkt_ptr++;
>   len = len * 256 + *pkt_ptr++;
> or again variants, but critically with a sequence point somehow.

If we could throw away sequence points and have left-to-right evaluation,
we could simply write:

  length = 256 * *pkt_ptr++ + *pkt_ptr++;

Thus:

>> Each time you read a byte you advance the pointer you don't have to
>> keep track and count bytes yourself. So is the CRC field in byte 21 or
>> byte 22? Well it depends if the Qualifier option was selected.

Exactly.

> That works with an index variable also.
>   int i = 0; // or unsigned or size_t
>   type = pkt[i++];
>   len = pkt[i] * 256 + pkt[i+1]; i += 2;
> or other variants similarly.

When I write this kind of code, I have the sense that I'm being the "human
compiler".

In my head I wrote this:

  length = 256 * *pkt_ptr++ + *pkt_ptr++;

But the nice, well-ordered language in my well-ordered mind has to be compiled
by hand into the disordered language in the machine, e.g.:

  length = 256 * *pkt_ptr++;
  length += *pkt_ptr++;

[toc] | [prev] | [next] | [standalone]

#17614

On 19.02.2012 06:53, Kaz Kylheku wrote:
> If we could throw away sequence points and have left-to-right evaluation,
> we could simply write:
> 
>   length = 256 * *pkt_ptr++ + *pkt_ptr++;
> 

But we don't, so we can't. I don't get what your difficulties are with
that. C is the way it is, Java is different. In case you didn't notice,
Java is built on different principles: C's directive is "trust the
programmer" (though the inclusion of complex and imaginary numbers
somewhat goes against this) and Java's directive is "protect the
programmer from his own mistakes".

Where Java falls short is that the really bad mistakes programmers make
aren't the kind a compiler could find. But OK, there are nearly-as-bad
mistakes that Java takes care of nicely (memory-leaks, free-after-use,
access violations with corruption, ...). Only sometimes it is too
obsessive with that. Like, it doesn't let you use variables that may be
uninitialized. Which would be a lot more helpful if the compiler
actually made a proper data-flow analysis instead of the half-assed
stuff it's doing currently. Try the following test class:

public class Test {
    public static void main(String[] args)
    {
        int i;

        if (args.length > 3)
            i = 3;
        if (args.length <= 3)
            i = 2;
        System.out.println(i);
    }
}

and compare the output of the compiler with what you get from a decent C
compiler at highest warning level when fed this source code:

#include <stdio.h>

int main(int argc, char* argv[])
{
    int i;

    (void) argv;
    if (argc > 3)
        i = 3;
    if (argc <= 3)
        i = 2;

    printf("%d\n", i);
    return 0;
}

And I don't get what is so hard about

length = (pkt_ptr[0] << 8) + pkt_ptr[1];
pkt_ptr += 2;

either.

> Thus:
> 
>>> Each time you read a byte you advance the pointer you don't have to
>>> keep track and count bytes yourself. So is the CRC field in byte 21 or
>>> byte 22? Well it depends if the Qualifier option was selected.
> 
> Exactly.
> 
>> That works with an index variable also.
>>   int i = 0; // or unsigned or size_t
>>   type = pkt[i++];
>>   len = pkt[i] * 256 + pkt[i+1]; i += 2;
>> or other variants similarly.
> 
> When I write this kind of code, I have the sense that I'm being the "human
> compiler".
> 
> In my head I wrote this:
> 
>   length = 256 * *pkt_ptr++ + *pkt_ptr++;
> 

If you want to write a line like this, you can! Just don't feed it a C
compiler, but Java, if that's what you want.

Otherwise, why don't you just build a C compiler with that rule
implemented? The behaviour is undefined by C which means that your
compiler would still be conforming.

> But the nice, well-ordered language in my well-ordered mind has to be compiled
> by hand into the disordered language in the machine, e.g.:
> 
>   length = 256 * *pkt_ptr++;
>   length += *pkt_ptr++;
> 

You really don't know what compiling by hand is. If you were ever in a
situation where operator overloading of C++ truly was helpful, then
you'll know if you had to rewrite that stuff into C. (Yeah, I think the line

y = 2 * x + 15 * a + (b - c) / d;

was better than the block

{
    Rational t1, t2, t3;
    rat_set_i(&t1, 2, 1);
    rat_mul(&t1, &t1, &x);
    rat_set_i(&t2, 15, 1);
    rat_mul(&t2, &t2, &a);
    rat_add(&t1, &t1, &t2);
    rat_sub(&t3, &b, &c);
    rat_div(&t3, &t3, &d);
    rat_add(&y, &t1, &t3);
}

)

Ciao,
Markus

[toc] | [prev] | [next] | [standalone]

#17615

Markus Wichmann wrote:
) You really don't know what compiling by hand is. If you were ever in a
) situation where operator overloading of C++ truly was helpful, then
) you'll know if you had to rewrite that stuff into C. (Yeah, I think the line
)
) y = 2 * x + 15 * a + (b - c) / d;
)
) was better than the block
)
) {
)     Rational t1, t2, t3;
)     rat_set_i(&t1, 2, 1);
)     rat_mul(&t1, &t1, &x);
)     rat_set_i(&t2, 15, 1);
)     rat_mul(&t2, &t2, &a);
)     rat_add(&t1, &t1, &t2);
)     rat_sub(&t3, &b, &c);
)     rat_div(&t3, &t3, &d);
)     rat_add(&y, &t1, &t3);
) }

That's a bit unfair (just a bit though):

  y = rat_add(rat_mul(rat_int(2), x),
        rat_add(rat_mul(rat_int(15), a),
          rat_div(rat_sub(b, c), d)));


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#17622

"Markus Wichmann" <nullplan@gmx.net> ha scritto nel messaggio
news:rjp719-cl5.ln1@voyager.wichi.de.vu...

> y = 2 * x + 15 * a + (b - c) / d;

> was better than the block
>
> {
>    Rational t1, t2, t3;
>    rat_set_i(&t1, 2, 1);
>    rat_mul(&t1, &t1, &x);
>    rat_set_i(&t2, 15, 1);
>    rat_mul(&t2, &t2, &a);
>    rat_add(&t1, &t1, &t2);
>    rat_sub(&t3, &b, &c);
>    rat_div(&t3, &t3, &d);
>    rat_add(&y, &t1, &t3);
> }
>
> )

the right way for that above
computation can not be far different from this:

multAssign(&y,  2,  x)|jc  .e
multAssign(&t, 15,  a)|jc  .e
 sumAssign(&r,  y,  t)|jc  .e
 difAssign(&y,  b,  c)|jc  .e
 divAssign(&t,  y,  d)|jc  .e
 sumAssign(&y,  r,  t)|jc  .e

[the code above is a pseudo C++ where for example
multAssign() is "i32 multAssign(num*  a,  i32  i, num&  b)"
and jc .e means if there is one error go to .e]

or pheraps
multAssign(y,  2,  x)|jc  .e
multAssign(t, 15,  a)|jc  .e
 sumAssign(r,  y,  t)|jc  .e
 difAssign(y,  b,  c)|jc  .e
 divAssign(t,  y,  d)|jc  .e
 sumAssign(y,  r,  t)|jc  .e

where all arg of function are pointers so 15 is a pointer in mem
of one number that contain 15

or pheraps
if( Assign(y, 2*x+15*a+(b-c)/d)!=0 ) goto error;
return 0;
error:
return -1;

or pheraps
if( (y:=2*x+15*a+(b-c)/d))!=0 ) goto error;
return 0;
error:
return -1;

so operator := return different of zero if error in assignament
or in the computation of assignament
zero if the assignament is the right result...

> Ciao,
> Markus

ciao

[toc] | [prev] | [next] | [standalone]

#17646

On 19.02.2012 19:54, Stefan Ram wrote:
> Markus Wichmann <nullplan@gmx.net> writes:
>> if (args.length > 3)
>>    i = 3;
>> if (args.length <= 3)
>>    i = 2;
> 
>   But in this special case, an if-then-else would be nicer.
>   And then you can even declare »i« as constant in Java:
> 
> { final int i; if( args.length > 3 )i = 3; else i = 2; ... }
> 
>   Though I'd always prefer
> 
> final int i =( args.length > 3 )3 : 2;
> 
>   .
> 


The example was chosen deliberately to show the flaws in the Java
data-flow analyzer: With if-else the code compiles, without it, the
compiler aborts on account of "i may not be initialized".

gcc does not generate a "may not be initialized" warning in the C code I
wrote below that (yes, I know that I have to activate the optimizer to
see those). Which means it is entirely possible for a program to see
that there is no code path to a read on i without prior initialization.

And by now we got totally off-topic...

Ciao,
Markus

[toc] | [prev] | [next] | [standalone]

#17734

On Feb 19, 5:54 pm, Markus Wichmann <nullp...@gmx.net> wrote:
> On 19.02.2012 06:53, Kaz Kylheku wrote:

> >   length = 256 * *pkt_ptr++ + *pkt_ptr++;

> And I don't get what is so hard about

> length = (pkt_ptr[0] << 8) + pkt_ptr[1];
> pkt_ptr += 2;

One piece of code is intended to demonstrate how smart the programmer
is.
One piece of code intended to be understood, debugged and maintained
by humans, though personally I'd prefer (pkt_ptr[0] * 256).

[toc] | [prev] | [next] | [standalone]

#17604

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.

That book is completely and utterly wrong.
In C, "array[index]" is *exactly the same* as "*(array + index)"
I would go so far as to call it syntactic sugar.
Hell, it's even commutative.  "array[index]" means the same as "index[array]" !

) Another book says that the syntax array[1] is
) only used by FORTRAN programmers who do not understand c pointers.

That sounds like nothing but evangelism.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#17621

Willem <willem@toad.stack.nl> writes:
> 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.
>
> That book is completely and utterly wrong.
> In C, "array[index]" is *exactly the same* as "*(array + index)"
> I would go so far as to call it syntactic sugar.
> Hell, it's even commutative.  "array[index]" means the same as "index[array]" !
[...]

Yes, but I doubt that that's what the book actually said.  I'm only
guessing, but the book was probably advocating code like this:

    void func(char *s) {
        while (*s != '\0') {
            do_something_with(*s);
            s++;
        }
    }

over this:

    void func(char *s) {
        size_t i = 0;
        while (s[i] != '\0') {
            do_something_with(s[i]);
            i++;
        }
    }

The former, by updating the pointer on each iteration, avoids
redoing the index calculation, which might be moderately expenstive,
especially for arrays of something bigger than char.

It's a largely obsolete argument, since modern optimizing compilers can
generate the same code for both, but it's not "completely and utterly
wrong".

I'd be interested in knowing which book the previous poster was
referring to, how old it is, and what it actually says.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#17626

Keith Thompson wrote:
) Willem <willem@toad.stack.nl> writes:
)> 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.
)>
)> That book is completely and utterly wrong.
)> In C, "array[index]" is *exactly the same* as "*(array + index)"
)> I would go so far as to call it syntactic sugar.
)> Hell, it's even commutative.  "array[index]" means the same as "index[array]" !
) [...]
)
) Yes, but I doubt that that's what the book actually said.

Granted.

) I'm only
) guessing, but the book was probably advocating code like this:
)
)     void func(char *s) {
)         while (*s != '\0') {
)             do_something_with(*s);
)             s++;
)         }
)     }
)
) over this:
)
)     void func(char *s) {
)         size_t i = 0;
)         while (s[i] != '\0') {
)             do_something_with(s[i]);
)             i++;
)         }
)     }
)
) The former, by updating the pointer on each iteration, avoids
) redoing the index calculation, which might be moderately expenstive,
) especially for arrays of something bigger than char.

Or which might not be expensive at all, especially given special indexing
instructions such as those on the x86.  Also for types bigger than char.

A long time ago, I did some speed tests on an x86 machine, and it turned
out that there was no speed difference whatsoever between an indexed loop
and a pointer loop.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#17627

Willem <willem@toad.stack.nl> writes:

> Keith Thompson wrote:
<snip>
> ) I'm only
> ) guessing, but the book was probably advocating code like this:
> )
> )     void func(char *s) {
> )         while (*s != '\0') {
> )             do_something_with(*s);
> )             s++;
> )         }
> )     }
> )
> ) over this:
> )
> )     void func(char *s) {
> )         size_t i = 0;
> )         while (s[i] != '\0') {
> )             do_something_with(s[i]);
> )             i++;
> )         }
> )     }
> )
> ) The former, by updating the pointer on each iteration, avoids
> ) redoing the index calculation, which might be moderately expenstive,
> ) especially for arrays of something bigger than char.
>
> Or which might not be expensive at all, especially given special indexing
> instructions such as those on the x86.  Also for types bigger than char.
>
> A long time ago, I did some speed tests on an x86 machine, and it turned
> out that there was no speed difference whatsoever between an indexed loop
> and a pointer loop.

With a relatively recent gcc, there's no need to test, at least for this
code.  You get the same instructions for the loop body (with -O2) for
both loops.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17705

Keith Thompson wrote:
> 
> Willem <willem@toad.stack.nl> writes:
> > 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.
> >
> > That book is completely and utterly wrong.
> > In C, "array[index]" is *exactly the same* as "*(array + index)"
> > I would go so far as to call it syntactic sugar.
> > Hell, it's even commutative.  "array[index]" means the same as "index[array]" !
> [...]
> 
> Yes, but I doubt that that's what the book actually said. 

Teach Yourself C, 
by Herbert Schildt, copyright 1990,
Chapter 6.3, Use Pointers With Arrays, 
page 197:

    For somewhat complex reasons, 
    a C compiler will generally create faster executable code
    for an expression such as

    *(p+3)

    than it will for the comparable array index

    p[3]

-- 
pete

[toc] | [prev] | [next] | [standalone]

#17712

On 02/20/2012 05:32 PM, pete wrote:
...
> Teach Yourself C, 
> by Herbert Schildt, copyright 1990,
> Chapter 6.3, Use Pointers With Arrays, 
> page 197:
> 
>     For somewhat complex reasons, 
>     a C compiler will generally create faster executable code
>     for an expression such as
> 
>     *(p+3)
> 
>     than it will for the comparable array index
> 
>     p[3]

Schildt is a notoriously unreliable source of information about C. It's
possible that what he said was true for some of the compilers he was
most familiar with at the time he wrote that - but I wouldn't recommend
assuming that this was the case. It's certainly not generally true, and
it's far less likely to be the case for modern compiler than it was for
those available in 1990.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#17715

pete <pfiland@mindspring.com> writes:
> Keith Thompson wrote:
>> Willem <willem@toad.stack.nl> writes:
>> > 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.
>> >
>> > That book is completely and utterly wrong.
>> > In C, "array[index]" is *exactly the same* as "*(array + index)"
>> > I would go so far as to call it syntactic sugar.
>> > Hell, it's even commutative.  "array[index]" means the same as "index[array]" !
>> [...]
>> 
>> Yes, but I doubt that that's what the book actually said. 
>
> Teach Yourself C, 
> by Herbert Schildt, copyright 1990,
> Chapter 6.3, Use Pointers With Arrays, 
> page 197:
>
>     For somewhat complex reasons, 
>     a C compiler will generally create faster executable code
>     for an expression such as
>
>     *(p+3)
>
>     than it will for the comparable array index
>
>     p[3]

Had I known it was one of Schildt's books, I wouldn't have assumed
that it said something sensible.  (Do we know that that's the book to
which peter was referring?)

Willem is right: the book is completely and utterly wrong.
There's probably a valid point somewhere in the vicinity of what
Schildt wrote (as I discussed upthread), but Schildt missed it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#17718

Keith Thompson <kst-u@mib.org> writes:
> pete <pfiland@mindspring.com> writes:
>> Keith Thompson wrote:
>>> Willem <willem@toad.stack.nl> writes:
>>> > 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.
>>> >
>>> > That book is completely and utterly wrong.
>>> > In C, "array[index]" is *exactly the same* as "*(array + index)"
>>> > I would go so far as to call it syntactic sugar.
>>> > Hell, it's even commutative.  "array[index]" means the same as "index[array]" !
>>> [...]
>>> 
>>> Yes, but I doubt that that's what the book actually said. 
>>
>> Teach Yourself C, 
>> by Herbert Schildt, copyright 1990,
>> Chapter 6.3, Use Pointers With Arrays, 
>> page 197:
>>
>>     For somewhat complex reasons, 
>>     a C compiler will generally create faster executable code
>>     for an expression such as
>>
>>     *(p+3)
>>
>>     than it will for the comparable array index
>>
>>     p[3]
>
> Had I known it was one of Schildt's books, I wouldn't have assumed
> that it said something sensible.  (Do we know that that's the book to
> which peter was referring?)
>
> Willem is right: the book is completely and utterly wrong.
> There's probably a valid point somewhere in the vicinity of what
> Schildt wrote (as I discussed upthread), but Schildt missed it.

Let me amend that slightly.  It's possible that some compilers might
generate faster code for *(p+3) than for p[3].  There's no good reason
for that, since the two expressions are equivalent by definition, but
it's possible.  It's also possible Schildt encountered such a compiler
and reached an overly general conclusion.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#17725

Keith Thompson wrote:
> 
> Keith Thompson <kst-u@mib.org> writes:
> > pete <pfiland@mindspring.com> writes:
> >> Keith Thompson wrote:
> >>> Willem <willem@toad.stack.nl> writes:
> >>> > 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.
> >>> >
> >>> > That book is completely and utterly wrong.
> >>> > In C, "array[index]" is *exactly the same* as "*(array + index)"
> >>> > I would go so far as to call it syntactic sugar.
> >>> > Hell, it's even commutative.  "array[index]" means the same as "index[array]" !
> >>> [...]
> >>>
> >>> Yes, but I doubt that that's what the book actually said.
> >>
> >> Teach Yourself C,
> >> by Herbert Schildt, copyright 1990,
> >> Chapter 6.3, Use Pointers With Arrays,
> >> page 197:
> >>
> >>     For somewhat complex reasons,
> >>     a C compiler will generally create faster executable code
> >>     for an expression such as
> >>
> >>     *(p+3)
> >>
> >>     than it will for the comparable array index
> >>
> >>     p[3]
> >
> > Had I known it was one of Schildt's books, I wouldn't have assumed
> > that it said something sensible.  (Do we know that that's the book to
> > which peter was referring?)


I don't know, 
but for some reason I remembered reading it a long time ago.


> > Willem is right: the book is completely and utterly wrong.
> > There's probably a valid point somewhere in the vicinity of what
> > Schildt wrote (as I discussed upthread), but Schildt missed it.
> 
> Let me amend that slightly.  It's possible that some compilers might
> generate faster code for *(p+3) than for p[3].  There's no good reason
> for that, since the two expressions are equivalent by definition, but
> it's possible.  It's also possible Schildt encountered such a compiler
> and reached an overly general conclusion.

I recall a thread about a year or so ago,
where the controling expression in a loop 
was shown to have been rendered
with a register, when {!= 0} was omitted.
That is to say that there was a compiler for which
    while (x)
was faster than
    while ((x) != 0)
I think it was a gcc compiler
and I remember being disappointed 
that the compiler had translated 
two semantically equal expressions differently.


-- 
pete

[toc] | [prev] | [next] | [standalone]

#17727

pete <pfiland@mindspring.com> writes:
[...]
> I recall a thread about a year or so ago,
> where the controling expression in a loop 
> was shown to have been rendered
> with a register, when {!= 0} was omitted.
> That is to say that there was a compiler for which
>     while (x)
> was faster than
>     while ((x) != 0)
> I think it was a gcc compiler
> and I remember being disappointed 
> that the compiler had translated 
> two semantically equal expressions differently.

That would be relevant only if it behaved that way with optimization
enabled.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web