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

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

Why C has Pointers.

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

Contents

  Why C has Pointers. curixinfotech <curixinfotech.54dl3z@no-mx.forums.yourdomain.com.au> - 2011-12-07 07:22 -0500
    Re: Why C has Pointers. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-07 04:35 -0800
    Re: Why C has Pointers. Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-07 07:58 -0500
      Re: Why C has Pointers. Mike Manilone <zhtx10@gmail.com> - 2011-12-07 13:15 +0000
        Re: Why C has Pointers. Bill Reid <hormelfree@gmail.com> - 2011-12-08 06:29 -0800
    Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-07 14:50 +0100
      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-07 11:01 -0800
        Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-12-07 20:49 +0100
        Re: Why C has Pointers. Brian <nospam@nospam.com> - 2011-12-07 20:00 +0000
          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-07 15:30 -0500
            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-07 12:43 -0800
              Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-07 13:09 -0800
            Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-08 19:39 +0100
              Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-08 14:16 -0500
                Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-08 20:23 +0100
      Re: Why C has Pointers. Kaz Kylheku <kaz@kylheku.com> - 2011-12-07 20:48 +0000
        Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-12-07 22:07 +0100
        Re: Why C has Pointers. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-10 07:34 +0000
    Re: Why C has Pointers. August Karlstrom <fusionfile@gmail.com> - 2011-12-07 16:16 +0100
    Re: Why C has Pointers. Borax Man <rotflol2@hotmail.com> - 2011-12-08 18:32 +1100
      Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-08 00:20 -0800
        Re: Why C has Pointers. André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-08 13:44 +0100
          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-09 05:04 -0800
            Re: Why C has Pointers. gazelle@shell.xmission.com (Kenny McCormack) - 2011-12-09 14:59 +0000
              Re: Why C has Pointers. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-09 20:19 -0800
              Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-10 07:36 -0800
    Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-08 00:12 -0800
    Re: Why C has Pointers. Cong Wang <xiyou.wangcong@gmail.com> - 2011-12-15 07:26 +0000
    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 08:51 -0800
      Re: Why C has Pointers. Barry Schwarz <schwarzb@dqel.com> - 2011-12-17 10:10 -0800
        Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 14:28 -0600
          Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 15:00 -0600
          Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-17 13:55 -0800
            Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 18:27 -0600
              Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-18 01:26 +0000
                Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 22:34 -0600
                  Re: Why C has Pointers. "Philip Lantz" <prl@canterey.us> - 2011-12-17 23:48 -0800
                    Re: Why C has Pointers. superpollo <superpollo@tznvy.pbz> - 2011-12-18 11:06 +0100
                  Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-18 13:44 +0000
                  Re: Why C has Pointers. pete <pfiland@mindspring.com> - 2011-12-18 11:05 -0500
                  Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-18 11:50 -0500
                  Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-18 13:10 -0800
                    Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-27 16:03 -0600
                      Re: Why C has Pointers. Barry Schwarz <schwarzb@dqel.com> - 2011-12-27 14:40 -0800
                      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 15:08 -0800
                        Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-27 20:09 -0600
                          Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 23:00 -0800
                          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:53 -0800
                          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-28 08:39 -0500
                      Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-27 18:14 -0500
                        Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 15:36 -0800
                          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-27 18:53 -0500
                      Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 13:20 +0000
                  Re: Why C has Pointers. John Bode <jfbode1029@gmail.com> - 2011-12-28 08:42 -0800
                Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 20:36 -0800
                  Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 04:56 +0000
                    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 21:37 -0800
                      Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 05:42 +0000
                        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 08:08 -0800
                          Re: Why C has Pointers. Robert Wessel <robertwessel2@yahoo.com> - 2011-12-18 10:36 -0600
                          Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 18:50 +0000
                          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:39 -0800
                          Re: Why C has Pointers. gordonb.1i27q@burditt.org (Gordon Burditt) - 2011-12-21 22:34 -0600
                        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 07:56 -0800
                          Re: Why C has Pointers. John Tsiombikas <nuclear@member.fsf.org> - 2011-12-19 18:38 +0000
                            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 13:47 -0800
                              Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:58 -0800
                                Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-28 03:21 -0800
              Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-18 13:07 -0800
                Re: Why C has Pointers. "io_x" <a@b.c.invalid> - 2011-12-19 04:02 +0100
          Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 15:35 -0800
            Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 18:41 -0600
          Re: Why C has Pointers. John Bode <jfbode1029@gmail.com> - 2011-12-19 05:14 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 09:50 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-09 15:48 -0800
          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-10 00:21 -0800
            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-10 01:03 -0800
      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-17 11:45 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 15:18 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 14:10 -0800
          Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-20 10:46 -0800
    Re: Why C has Pointers. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-12-17 19:15 +0100
      Re: Why C has Pointers. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-12-17 19:19 +0100
        Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:48 -0800
    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 11:05 -0800
      Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:48 -0800

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

#14387

On Dec 8, 7:32 am, Borax Man <rotfl...@hotmail.com> wrote:
> curixinfotech wrote:
> > parshant

> I can't believe how many people responded to this spam.

in what sense is it spam? Is it widely posted? Is it off-topic? Is it
cross posted? Has it been repeatedly posted? Does it originate from a
bank employee in Bukino Fasu?

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

#14391

Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On Dec 8, 7:32 am, Borax Man <rotfl...@hotmail.com> wrote:
> > curixinfotech wrote:
> > > parshant
> 
> > I can't believe how many people responded to this spam.
> 
> in what sense is it spam? Is it widely posted? Is it off-topic? Is it
> cross posted? Has it been repeatedly posted? Does it originate from a
> bank employee in Bukino Fasu?

It's troll, not spam.

-- 
André Gillibert

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

#14422

On Dec 8, 12:44 pm, André Gillibert <MetaEntropy.removeT...@gmail.com>
wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > On Dec 8, 7:32 am, Borax Man <rotfl...@hotmail.com> wrote:
> > > curixinfotech wrote:
> > > > parshant
>
> > > I can't believe how many people responded to this spam.
>
> > in what sense is it spam? Is it widely posted? Is it off-topic? Is it
> > cross posted? Has it been repeatedly posted? Does it originate from a
> > bank employee in Bukino Fasu?
>
> It's troll, not spam.

I'm not sure even that's true. he may genuinely wondering what
pointers are for. It smells like homework though.

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

#14423

In article <68e27f18-0ad9-4309-b9e4-8386f49041ae@p16g2000yqd.googlegroups.com>,
Nick Keighley  <nick_keighley_nospam@hotmail.com> wrote:
>On Dec 8, 12:44 pm, André Gillibert <MetaEntropy.removeT...@gmail.com>
>wrote:
>> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>> > On Dec 8, 7:32 am, Borax Man <rotfl...@hotmail.com> wrote:
>> > > curixinfotech wrote:
>> > > > parshant
>>
>> > > I can't believe how many people responded to this spam.
>>
>> > in what sense is it spam? Is it widely posted? Is it off-topic? Is it
>> > cross posted? Has it been repeatedly posted? Does it originate from a
>> > bank employee in Bukino Fasu?
>>
>> It's troll, not spam.
>
>I'm not sure even that's true. he may genuinely wondering what
>pointers are for. It smells like homework though.

I go with troll (and "good on him!").

The real truth to keep in mind here is that the obvious answer to the
question is: Because the inventors (and subsequent maintainers) of the
language put them in.  I.e., the question is equivalent to "Why is the
background of the 'Mona Lisa' the color that it is?"  It is that color
because the artist made it that way.  That's really all there is to it.

The problem is that the question gets people's dander up - it incites them
to interpret the question as a criticism of the language.  Now, maybe that
is really what the questioner has in mind, but the fact remains that "we"
shouldn't take the bait.  We should just answer as above.

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

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

#14429

On Dec 9, 4:59 pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>
> The problem is that the question gets people's dander up - it incites them
> to interpret the question as a criticism of the language.  Now, maybe that
> is really what the questioner has in mind, but the fact remains that "we"
> shouldn't take the bait.  We should just answer as above.
>
In the early days of C, you sometimes heard of programmers being told,
"You can program in C as long as you don't use pointers". That's
impractical, of course.

But pointers can cause terrible problems. Most languages hide them
from the programmer. C doesn't, and it's entirely legitimate to
discuss that design decision.
--
Basic Algorithms: how do JPEG files work?
http://www.malcommclean.site11.com/www

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

#14441

On Dec 9, 2:59 pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <68e27f18-0ad9-4309-b9e4-8386f4904...@p16g2000yqd.googlegroups.com>,
> Nick Keighley  <nick_keighley_nos...@hotmail.com> wrote:
> >On Dec 8, 12:44 pm, André Gillibert <MetaEntropy.removeT...@gmail.com>
> >wrote:
> >> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >> > On Dec 8, 7:32 am, Borax Man <rotfl...@hotmail.com> wrote:
> >> > > curixinfotech wrote:
> >> > > > parshant


> >> > > I can't believe how many people responded to this spam.
>
> >> > in what sense is it spam? Is it widely posted? Is it off-topic? Is it
> >> > cross posted? Has it been repeatedly posted? Does it originate from a
> >> > bank employee in Bukino Fasu?
>
> >> It's troll, not spam.
>
> >I'm not sure even that's true. he may genuinely wondering what
> >pointers are for. It smells like homework though.
>
> I go with troll (and "good on him!").
>
> The real truth to keep in mind here is that the obvious answer to the
> question is: Because the inventors (and subsequent maintainers) of the
> language put them in.

not sure that's completly, or usefully, true. A programming languages
is designed (or intended to be) to be useful in expressing solutions
to certain classes of problem. I suspect Richie put some thought into
his pointers. He based them on BCPL but with subtle twists in both
syntax and semantics. In short I don't think C pointer are an
accident.

> I.e., the question is equivalent to "Why is the
> background of the 'Mona Lisa' the color that it is?"  It is that color
> because the artist made it that way.  That's really all there is to it.

again I suspect there were contraits on the colours Leonardo
considered. Magnolia or rainbow stripes were probably unlikely.

> The problem is that the question gets people's dander up - it incites them
> to interpret the question as a criticism of the language.  Now, maybe that
> is really what the questioner has in mind, but the fact remains that "we"
> shouldn't take the bait.  We should just answer as above.

I'm not the one saying the OP's a troll

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

#14386

On Dec 7, 12:22 pm, curixinfotech <curixinfotech.54d...@no-
mx.forums.yourdomain.com.au> wrote:

> my Q is on the c language tell me now why c has pointers.

why not?

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

#14615

On 2011-12-07, curixinfotech <curixinfotech.54dl3z@no-mx.forums.yourdomain.com.au> wrote:
>
> hi
> my Q is on the c language tell me now why c has pointers.
> parshant
>
>

Because C is designed like this, to operate on memory.

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#14656

On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> hi
> my Q is on the c language tell me now why c has pointers.
> parshant
> 
> 
> -- 
> curixinfotech
> ------------------------------------------------------------------------
> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319

OK, I'll explain how to use a pointer in C without any knowledge in the 
hardware or assembly here.
// 
int i;
int a[3]={ 1,2,3} ; // an array of 3 integers
int* ptr1; // Note the star should be right after int, not initialize
int* ptr2; // not initialized

ptr1=a; // Read this as  to make ptr1 to be an alias of a. 

for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
for(i=0;i<3;i++)  printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
//This is a shadow copy. 
ptr1[0]=6; ptr2[1]=6;
for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
// a[0]=? a[1]=?

//Deep copy is different.
ptr2=malloc(3*sizeof(int)); // get another array from the heap 
// if (ptr2==NULL) then raise an error!!!
memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy 
ptr2[0]=-6; *(ptr+2)=-6; 

for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
for(i=0;i<3;i++)  printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
for(i=0;i<3;i++)  printf("The value of ptr2[%d]=%d.\n", i, ptr2[i]);

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

#14657

On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
<dihedral88888@googlemail.com> wrote:

>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
>> hi
>> my Q is on the c language tell me now why c has pointers.
>> parshant
>> 
>> 
>> -- 
>> curixinfotech
>> ------------------------------------------------------------------------
>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
>
>OK, I'll explain how to use a pointer in C without any knowledge in the 
>hardware or assembly here.
>// 
>int i;
>int a[3]={ 1,2,3} ; // an array of 3 integers
>int* ptr1; // Note the star should be right after int, not initialize
>int* ptr2; // not initialized
>
>ptr1=a; // Read this as  to make ptr1 to be an alias of a. 

If that were true, the sizeof(a) and sizeof(ptr1) would be equal
which, in the general case, they are not.  ptr1 is simply a pointer
that points to the start of a.  Even though they share some
similarities in the language syntax, a pointer is a completely
different type than an array.  Calling one an alias of the other just
breeds unnecessary confusion.

>
>for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
>for(i=0;i<3;i++)  printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
>//This is a shadow copy. 
>ptr1[0]=6; ptr2[1]=6;

Since ptr2 was never initialized or assigned a value, the second
statement invokes undefined behavior.  It is probably a typo and ptr1
was intended.

ptr1 points to a.  There is no copy.  a[0] and ptr1[0] refer to the
exact same object.

>for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
>// a[0]=? a[1]=?
>
>//Deep copy is different.
>ptr2=malloc(3*sizeof(int)); // get another array from the heap 
>// if (ptr2==NULL) then raise an error!!!
>memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy 
>ptr2[0]=-6; *(ptr+2)=-6; 

Since there is no variable ptr, this cannot compile.  Was *(ptr2+2)
intended?

>
>for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
>for(i=0;i<3;i++)  printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
>for(i=0;i<3;i++)  printf("The value of ptr2[%d]=%d.\n", i, ptr2[i]);

a[i] and ptr1[i] still point to the same object.  ptr2 points to a
different area of memory which at one time had a copy of a but has
since been assigned at least one different value.

-- 
Remove del for email

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

#14661

On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <schwarzb@dqel.com>
wrote:

>On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
><dihedral88888@googlemail.com> wrote:
>
>>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
>>> hi
>>> my Q is on the c language tell me now why c has pointers.
>>> parshant
>>> 
>>> 
>>> -- 
>>> curixinfotech
>>> ------------------------------------------------------------------------
>>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
>>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
>>
>>OK, I'll explain how to use a pointer in C without any knowledge in the 
>>hardware or assembly here.
>>// 
>>int i;
>>int a[3]={ 1,2,3} ; // an array of 3 integers
>>int* ptr1; // Note the star should be right after int, not initialize
>>int* ptr2; // not initialized
>>
>>ptr1=a; // Read this as  to make ptr1 to be an alias of a. 
>
>If that were true, the sizeof(a) and sizeof(ptr1) would be equal
>which, in the general case, they are not.  ptr1 is simply a pointer
>that points to the start of a.  Even though they share some
>similarities in the language syntax, a pointer is a completely
>different type than an array.  Calling one an alias of the other just
>breeds unnecessary confusion.
>

I agree. 

I have trouble understanding the constant confusion between arrays and
pointers. Way back when (and we are talking many moons ago <g>) when I
started out in C my mentor explained it very simply in these terms in
the first couple of days.

1) There is a difference between declarations and definitions.
Remember which you are dealing with and when.
2) A pointer is a "variable", an array is a "constant"
3) The array name evaluates to the address of the first element in the
array.
4) A pointer is a variable that holds the address of another variable
or an array.
5) All pointers must be intialized before you use them.
6) Since an array name is an address it can be used as a pointer that
is initialized to point to the first element in the array. 
7) *variable means the contents of the variable.
8) &variable means the address of the variable.
9) The array operator evaluates to a storage map equation, eg.
    type ar[i] := *(a + (i * sizeof(type))
10) In all "pointer" operations you are either chewing on an address
or the contents (value) at that address. Simple deconstrution of the
even the most complex expression will quickly reveal which it is.

I've since learned how to restate the above in fancier terminology,
but those simple rules have stuck and served me well from my second
week in C to today - thirty plus years later.

-ralph

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

#14662

On Sat, 17 Dec 2011 14:28:14 -0600, ralph <nt_consulting64@yahoo.net>
wrote:
I should probably amplify #1 ...

>
>1) There is a difference between declarations and definitions.
>Remember which you are dealing with and when.

1.5) C operators are overloaded to some extent and often a different
meaning in a declaration opposed to a definition or expression. For
example:
   *v means the contents (value) of the variable pointed to by v in an
expression, but 
   char* v means declare a pointer that holds the address of a
variable that holds a char in a declaration.

...

-ralph

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

#14663

ralph <nt_consulting64@yahoo.net> writes:
[...]
> I have trouble understanding the constant confusion between arrays and
> pointers. Way back when (and we are talking many moons ago <g>) when I
> started out in C my mentor explained it very simply in these terms in
> the first couple of days.
>
> 1) There is a difference between declarations and definitions.
> Remember which you are dealing with and when.
> 2) A pointer is a "variable", an array is a "constant"

That doesn't really make sense.  An array variable is not a constant:

    int arr[10];
    arr[5] = 42;

I suppose what it means is that an array name, when it appears in an
expression (in most but not all context) decays to a pointer to the
array's first element, and that pointer value cannot be modified.  But I
think that saying an array is a constant just reinforces the confusion
between arrays and pointers.

> 3) The array name evaluates to the address of the first element in the
> array.

This applies to any expression of array type, not just the name of a
declared array object.  But it doesn't apply in all contexts.
Specifically, an expression of array type is converted to a pointer to
the array object's first element *unless* it's:

    The operand of a unary "sizeof" operator (sizeof arr gives you the
    same of the array, not of a pointer);

    The operand of a unary "&" operator (&arr gives you the address of
    the array object; it's the same memory location as the address of
    its first element, but it's of a different type);

    A string literal in an initializer used to initialize an array
    object.  In
        char arr[6] = "hello";
    the *value* of "hello" is copied into arr.

> 4) A pointer is a variable that holds the address of another variable
> or an array.

The distinction between variables an arrays is unnecessary.  Variables
can be of any object type: integer, floating-point, struct, union,
array, pointer.  There's nothing special about arrays in that particular
context.

An array object is an object whose value consists of the values of its
elements, just as a struct object is an object whose value consists of
the values of its members.

> 5) All pointers must be intialized before you use them.

The same applies to any object.

> 6) Since an array name is an address it can be used as a pointer that
> is initialized to point to the first element in the array. 

In most contexts; see above.  It would be clearer to say that an array
name *decays to* an address (or pointer value).  And I wouldn't use the
word "initialized".

> 7) *variable means the contents of the variable.

No, it means the contents of the object to which "variable" points (and
is valid only if "variable" is of pointer type).

> 8) &variable means the address of the variable.
> 9) The array operator evaluates to a storage map equation, eg.
>     type ar[i] := *(a + (i * sizeof(type))

I'm not sure what syntax you're using.  What does "type" mean here?  And
C pointer arithmetic is already scaled by the size of the pointed-to
type.

arr[i] is by definition equivalent to *(arr + i).

> 10) In all "pointer" operations you are either chewing on an address
> or the contents (value) at that address. Simple deconstrution of the
> even the most complex expression will quickly reveal which it is.
>
> I've since learned how to restate the above in fancier terminology,
> but those simple rules have stuck and served me well from my second
> week in C to today - thirty plus years later.

Section 6 of the comp.lang.c FAQ, <http://c-faq.com>, has an excellent
explanation of the relationship between arrays and pointers.

A digression: The rule that an array expression decays into a pointer to
the array object's first element leads to an interesting little hole in
the language.  It assumes that there is an array *object* to which you
can point.  This is usually the case, but not always.  For example:

#include <stdio.h>

struct foo {
    int arr[3];
};

struct foo func(void) {
    struct foo result = { { 10, 20, 30 } };
    return result;
}

int main(void) {
    int *ptr = func().arr;
    printf("*ptr = %d\n", *ptr);
    return 0;
}

func() returns a *value* of type struct foo; it doesn't refer to any
object ("result" ceases to exist when the function returns).  So we have
an array value, a member of the struct value returned by func(), that is
not the value of any array object.

C201X addresses this.

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

#14670

On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>ralph <nt_consulting64@yahoo.net> writes:
>[...]
>> I have trouble understanding the constant confusion between arrays and
>> pointers. Way back when (and we are talking many moons ago <g>) when I
>> started out in C my mentor explained it very simply in these terms in
>> the first couple of days.
>>
>> 1) There is a difference between declarations and definitions.
>> Remember which you are dealing with and when.
>> 2) A pointer is a "variable", an array is a "constant"
>
>That doesn't really make sense.  An array variable is not a constant:
>
>    int arr[10];
>    arr[5] = 42;
>
>I suppose what it means is that an array name, when it appears in an
>expression (in most but not all context) decays to a pointer to the
>array's first element, and that pointer value cannot be modified.  But I
>think that saying an array is a constant just reinforces the confusion
>between arrays and pointers.
>

I disagree. 

Once the beginner gets it through his head that you can never do an
assignment to 'arr' you resolve a ton of the questions we get around
here. That as close to the definition of a "constant" as you can get.

-ralph

     
>> 3) The array name evaluates to the address of the first element in the
>> array.
>
>This applies to any expression of array type, not just the name of a
>declared array object.  But it doesn't apply in all contexts.
>Specifically, an expression of array type is converted to a pointer to
>the array object's first element *unless* it's:
>
>    The operand of a unary "sizeof" operator (sizeof arr gives you the
>    same of the array, not of a pointer);
>
>    The operand of a unary "&" operator (&arr gives you the address of
>    the array object; it's the same memory location as the address of
>    its first element, but it's of a different type);
>
>    A string literal in an initializer used to initialize an array
>    object.  In
>        char arr[6] = "hello";
>    the *value* of "hello" is copied into arr.
>

Yep. But what's the big deal. 

And of course I disagree that it actually matters to the beginner that
the address is of a "different type". Semantically and syntactically
it comes out the same. Plenty of time to get into vague language
later.

Actually in some implementations whether "hello" gets copied and when
if gets copied if it does depends on context. Again, why add
confusion?

[You can also create snippets that demonstrate that "hello" are
identical "constants" ...
   "hello"[3];    \\ 'l'
   arr[3];         \\ 'l'


>> 4) A pointer is a variable that holds the address of another variable
>> or an array.
>
>The distinction between variables an arrays is unnecessary.  Variables
>can be of any object type: integer, floating-point, struct, union,
>array, pointer.  There's nothing special about arrays in that particular
>context.
>
>An array object is an object whose value consists of the values of its
>elements, just as a struct object is an object whose value consists of
>the values of its members.
>
>> 5) All pointers must be intialized before you use them.
>
>The same applies to any object.
>
>> 6) Since an array name is an address it can be used as a pointer that
>> is initialized to point to the first element in the array. 
>
>In most contexts; see above.  It would be clearer to say that an array
>name *decays to* an address (or pointer value).  And I wouldn't use the
>word "initialized".
>

I would. And again what does 'decay' meant to the beginner?
In code the name "arr" is changed to, or evaluates to, the address of
the first element.

>> 7) *variable means the contents of the variable.
>
>No, it means the contents of the object to which "variable" points (and
>is valid only if "variable" is of pointer type).
>
>> 8) &variable means the address of the variable.
>> 9) The array operator evaluates to a storage map equation, eg.
>>     type ar[i] := *(a + (i * sizeof(type))
>
>I'm not sure what syntax you're using.  What does "type" mean here?  And
>C pointer arithmetic is already scaled by the size of the pointed-to
>type.
>
>arr[i] is by definition equivalent to *(arr + i).
>

Think about it. 

You say that now, but you come back later in other response to point
out "sizes". That "already scaled" is because the compiler knows the
type, and he knows the type because you declared it.


>> 10) In all "pointer" operations you are either chewing on an address
>> or the contents (value) at that address. Simple deconstrution of the
>> even the most complex expression will quickly reveal which it is.
>>
>> I've since learned how to restate the above in fancier terminology,
>> but those simple rules have stuck and served me well from my second
>> week in C to today - thirty plus years later.
>
>Section 6 of the comp.lang.c FAQ, <http://c-faq.com>, has an excellent
>explanation of the relationship between arrays and pointers.
>
>A digression: The rule that an array expression decays into a pointer to
>the array object's first element leads to an interesting little hole in
>the language.  It assumes that there is an array *object* to which you
>can point.  This is usually the case, but not always.  For example:
>
>#include <stdio.h>
>
>struct foo {
>    int arr[3];
>};
>
>struct foo func(void) {
>    struct foo result = { { 10, 20, 30 } };
>    return result;
>}
>
>int main(void) {
>    int *ptr = func().arr;
>    printf("*ptr = %d\n", *ptr);
>    return 0;
>}
>
>func() returns a *value* of type struct foo; it doesn't refer to any
>object ("result" ceases to exist when the function returns).  So we have
>an array value, a member of the struct value returned by func(), that is
>not the value of any array object.
>
>C201X addresses this.

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

#14672

ralph <nt_consulting64@yahoo.net> writes:

> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>ralph <nt_consulting64@yahoo.net> writes:
>>[...]
>>> I have trouble understanding the constant confusion between arrays and
>>> pointers. Way back when (and we are talking many moons ago <g>) when I
>>> started out in C my mentor explained it very simply in these terms in
>>> the first couple of days.
>>>
>>> 1) There is a difference between declarations and definitions.
>>> Remember which you are dealing with and when.
>>> 2) A pointer is a "variable", an array is a "constant"
>>
>>That doesn't really make sense.  An array variable is not a constant:
>>
>>    int arr[10];
>>    arr[5] = 42;
>>
>>I suppose what it means is that an array name, when it appears in an
>>expression (in most but not all context) decays to a pointer to the
>>array's first element, and that pointer value cannot be modified.  But I
>>think that saying an array is a constant just reinforces the confusion
>>between arrays and pointers.
>>
>
> I disagree. 
>
> Once the beginner gets it through his head that you can never do an
> assignment to 'arr' you resolve a ton of the questions we get around
> here. That as close to the definition of a "constant" as you can get.

I'd say that "unchanging" or "immutable" were closer definitions, and
arrays can be changed.

What you call a constant, I'd call a value, and I'd explain that
array-valued expressions are (usually) converted automatically to
pointer values.

Most people learning programming quickly get the idea of variables and
values.  Variables can be assigned to, but values can't.  This avoids
calling arrays "constant".  It's also a start towards some more
technical matters such as why

  int x;
  x = 0;

is ok, but

 (int)x = 0;

is not.

>>> 3) The array name evaluates to the address of the first element in the
>>> array.
>>
>>This applies to any expression of array type, not just the name of a
>>declared array object.  But it doesn't apply in all contexts.
>>Specifically, an expression of array type is converted to a pointer to
>>the array object's first element *unless* it's:
>>
>>    The operand of a unary "sizeof" operator (sizeof arr gives you the
>>    same of the array, not of a pointer);
>>
>>    The operand of a unary "&" operator (&arr gives you the address of
>>    the array object; it's the same memory location as the address of
>>    its first element, but it's of a different type);
>>
>>    A string literal in an initializer used to initialize an array
>>    object.  In
>>        char arr[6] = "hello";
>>    the *value* of "hello" is copied into arr.
>>
>
> Yep. But what's the big deal. 
>
> And of course I disagree that it actually matters to the beginner that
> the address is of a "different type". Semantically and syntactically
> it comes out the same. Plenty of time to get into vague language
> later.

I agree about putting this off, but 'arr' and '&arr' are not the same
semantically.  If they were,

  arr + 1

and

  &arr + 1

would have the same value but they don't.  (I'm using arr as defined
above.)

<snip>
>>In most contexts; see above.  It would be clearer to say that an array
>>name *decays to* an address (or pointer value).  And I wouldn't use the
>>word "initialized".
>
> I would. And again what does 'decay' meant to the beginner?
> In code the name "arr" is changed to, or evaluates to, the address of
> the first element.

I'd just say "converted".  C has lots of automatic conversions and,
sooner or later, these need to be explains.  The array to pointer
conversion fits into this general pattern.

<snip>
>>> 9) The array operator evaluates to a storage map equation, eg.
>>>     type ar[i] := *(a + (i * sizeof(type))
>>
>>I'm not sure what syntax you're using.  What does "type" mean here?  And
>>C pointer arithmetic is already scaled by the size of the pointed-to
>>type.
>>
>>arr[i] is by definition equivalent to *(arr + i).
>
> Think about it. 
>
> You say that now, but you come back later in other response to point
> out "sizes". That "already scaled" is because the compiler knows the
> type, and he knows the type because you declared it.

It's not easy to explain the lower-level arithmetic without reference to
some particular machine.  For example, on a machine with, say, byte and
word addresses, you can't describe it as you have done.  By all means,
take a simple architecture and explain what a[0] means on one particular
system using addresses and size calculations, but you will also have to
explain, eventually, that arr[i] is, by definition, *(arr + i).

<snip>
-- 
Ben.

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

#14673

On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>ralph <nt_consulting64@yahoo.net> writes:
>
>> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <kst-u@mib.org>
>> wrote:
>>
>>>ralph <nt_consulting64@yahoo.net> writes:
>>>[...]
>>>> I have trouble understanding the constant confusion between arrays and
>>>> pointers. Way back when (and we are talking many moons ago <g>) when I
>>>> started out in C my mentor explained it very simply in these terms in
>>>> the first couple of days.
>>>>
>>>> 1) There is a difference between declarations and definitions.
>>>> Remember which you are dealing with and when.
>>>> 2) A pointer is a "variable", an array is a "constant"
>>>
>>>That doesn't really make sense.  An array variable is not a constant:
>>>
>>>    int arr[10];
>>>    arr[5] = 42;
>>>
>>>I suppose what it means is that an array name, when it appears in an
>>>expression (in most but not all context) decays to a pointer to the
>>>array's first element, and that pointer value cannot be modified.  But I
>>>think that saying an array is a constant just reinforces the confusion
>>>between arrays and pointers.
>>>
>>
>> I disagree. 
>>
>> Once the beginner gets it through his head that you can never do an
>> assignment to 'arr' you resolve a ton of the questions we get around
>> here. That as close to the definition of a "constant" as you can get.
>
>I'd say that "unchanging" or "immutable" were closer definitions, and
>arrays can be changed.
>
>What you call a constant, I'd call a value, and I'd explain that
>array-valued expressions are (usually) converted automatically to
>pointer values.
>
>Most people learning programming quickly get the idea of variables and
>values.  Variables can be assigned to, but values can't.  This avoids
>calling arrays "constant".  It's also a start towards some more
>technical matters such as why
>
>  int x;
>  x = 0;
>
>is ok, but
>
> (int)x = 0;
>
>is not.
>
>>>> 3) The array name evaluates to the address of the first element in the
>>>> array.
>>>
>>>This applies to any expression of array type, not just the name of a
>>>declared array object.  But it doesn't apply in all contexts.
>>>Specifically, an expression of array type is converted to a pointer to
>>>the array object's first element *unless* it's:
>>>
>>>    The operand of a unary "sizeof" operator (sizeof arr gives you the
>>>    same of the array, not of a pointer);
>>>
>>>    The operand of a unary "&" operator (&arr gives you the address of
>>>    the array object; it's the same memory location as the address of
>>>    its first element, but it's of a different type);
>>>
>>>    A string literal in an initializer used to initialize an array
>>>    object.  In
>>>        char arr[6] = "hello";
>>>    the *value* of "hello" is copied into arr.
>>>
>>
>> Yep. But what's the big deal. 
>>
>> And of course I disagree that it actually matters to the beginner that
>> the address is of a "different type". Semantically and syntactically
>> it comes out the same. Plenty of time to get into vague language
>> later.
>
>I agree about putting this off, but 'arr' and '&arr' are not the same
>semantically.  If they were,
>
>  arr + 1
>
>and
>
>  &arr + 1
>
>would have the same value but they don't.  (I'm using arr as defined
>above.)
>
><snip>
>>>In most contexts; see above.  It would be clearer to say that an array
>>>name *decays to* an address (or pointer value).  And I wouldn't use the
>>>word "initialized".
>>
>> I would. And again what does 'decay' meant to the beginner?
>> In code the name "arr" is changed to, or evaluates to, the address of
>> the first element.
>
>I'd just say "converted".  C has lots of automatic conversions and,
>sooner or later, these need to be explains.  The array to pointer
>conversion fits into this general pattern.
>
><snip>
>>>> 9) The array operator evaluates to a storage map equation, eg.
>>>>     type ar[i] := *(a + (i * sizeof(type))
>>>
>>>I'm not sure what syntax you're using.  What does "type" mean here?  And
>>>C pointer arithmetic is already scaled by the size of the pointed-to
>>>type.
>>>
>>>arr[i] is by definition equivalent to *(arr + i).
>>
>> Think about it. 
>>
>> You say that now, but you come back later in other response to point
>> out "sizes". That "already scaled" is because the compiler knows the
>> type, and he knows the type because you declared it.
>
>It's not easy to explain the lower-level arithmetic without reference to
>some particular machine.  For example, on a machine with, say, byte and
>word addresses, you can't describe it as you have done.  By all means,
>take a simple architecture and explain what a[0] means on one particular
>system using addresses and size calculations, but you will also have to
>explain, eventually, that arr[i] is, by definition, *(arr + i).
>

Sure it is because it ain't *(arr + i). It is ...

*(arr + ( i * sizeof(datatype)))

So for int arr[10];
arr[5] is *(arr + (5 * sizeof(int)))
byte arr[10];
arr[5] is *(arr + (5 * sizeof(byte)))

You don't care what platform you are using because the sizeof takes
care of it. sizeof and size of datatypes are defined for each compiler
(which is platform specific by default). That's how pointer arithmetic
works. That's how the C language achieves platform independence and
compilers can be implemented for any specific architecture.

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

#14679

On Sat, 17 Dec 2011, ralph wrote:
> On Sun, 18 Dec 2011, Ben Bacarisse wrote:
>> ... arr[i] is, by definition, *(arr + i).
>>
>
> ... it ain't *(arr + i). It is ...
>
> *(arr + ( i * sizeof(datatype)))
>
> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))
>
> You don't care what platform you are using because the sizeof takes
> care of it. sizeof and size of datatypes are defined for each compiler
> (which is platform specific by default). That's how pointer arithmetic
> works. That's how the C language achieves platform independence and
> compilers can be implemented for any specific architecture.


Ralph, could you do me a favor, please, and run the following program,
and let us know what its output is for you?


#include <stdio.h>

int main(void)
{
     int arr[20] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
                     11,12,13,14,15,16,17,18,19,20 };

     printf("%d\n", arr[2]);
     printf("%d\n", *(arr + (2 * sizeof(int))));
     printf("%d\n", *(arr + 2));

     return 0;
}


Thanks.

Philip

P.S. I get:
3
17
3

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

#14681

Philip Lantz ha scritto:
> On Sat, 17 Dec 2011, ralph wrote:
>> On Sun, 18 Dec 2011, Ben Bacarisse wrote:
>>> ... arr[i] is, by definition, *(arr + i).
>>>
>>
>> ... it ain't *(arr + i). It is ...
>>
>> *(arr + ( i * sizeof(datatype)))
>>
>> So for int arr[10];
>> arr[5] is *(arr + (5 * sizeof(int)))
>> byte arr[10];
>> arr[5] is *(arr + (5 * sizeof(byte)))
>>
>> You don't care what platform you are using because the sizeof takes
>> care of it. sizeof and size of datatypes are defined for each compiler
>> (which is platform specific by default). That's how pointer arithmetic
>> works. That's how the C language achieves platform independence and
>> compilers can be implemented for any specific architecture.
> 
> 
> Ralph, could you do me a favor, please, and run the following program,
> and let us know what its output is for you?
> 
> 
> #include <stdio.h>
> 
> int main(void)
> {
>     int arr[20] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
>                     11,12,13,14,15,16,17,18,19,20 };
> 
>     printf("%d\n", arr[2]);
>     printf("%d\n", *(arr + (2 * sizeof(int))));
>     printf("%d\n", *(arr + 2));
> 
>     return 0;
> }
> 
> 
> Thanks.
> 
> Philip
> 
> P.S. I get:
> 3
> 17
> 3

i get:

3
9
3

bye

-- 
- La verdad amigo, es que en tu sangre, tienes mierda!
- Es posible, pero la mierda viva es mejor que la mierda muerta...
- Amigo... la mierda, siempre mierda es!!

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

#14684

ralph <nt_consulting64@yahoo.net> writes:

> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>ralph <nt_consulting64@yahoo.net> writes:
>>
>>> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <kst-u@mib.org>
<snip>
>>>>arr[i] is by definition equivalent to *(arr + i).
>>>
>>> Think about it. 
>>>
>>> You say that now, but you come back later in other response to point
>>> out "sizes". That "already scaled" is because the compiler knows the
>>> type, and he knows the type because you declared it.
>>
>>It's not easy to explain the lower-level arithmetic without reference to
>>some particular machine.  For example, on a machine with, say, byte and
>>word addresses, you can't describe it as you have done.  By all means,
>>take a simple architecture and explain what a[0] means on one particular
>>system using addresses and size calculations, but you will also have to
>>explain, eventually, that arr[i] is, by definition, *(arr + i).
>>
>
> Sure it is because it ain't *(arr + i). It is ...
>
> *(arr + ( i * sizeof(datatype)))
>
> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))

That's wrong, if what you are writing there are C expressions.  arr[5]
is defined to be the same as *(arr + 5).  Can you clear this up?  Do you
agree that

  arr[5] == *(arr + 5)

and

  &arr[5] == arr + 5

are C expressions that always evaluate to 1?  (Let's assume arr[5] has
been assigned some non-trap representation!)

You may be trying to explain arr[5] using a confusingly C-like
notation.  If so, that's a very confusing thing to do.  If I wanted to
explain what a compiler has to do, I'd use some entirely un-C-like
notation to avoid any possible misunderstanding.

> You don't care what platform you are using because the sizeof takes
> care of it. sizeof and size of datatypes are defined for each compiler
> (which is platform specific by default). That's how pointer arithmetic
> works.

Not always.  It's not sizeof that takes care of it, it's the compiler.
A C compiler must ensure that arr[i] and *(arr + i) have the same
meaning.  To do that, it must do something with machine addresses that
involves the size of the array elements, but it's not always as simple
as you suggest.  For example, I've used a machine where sizeof(int) is 2
but arr[5] (where arr is your int array from above) is implemented by
adding 5 (yes, 5, not 2*5) to the address of the array's first element.

> That's how the C language achieves platform independence and
> compilers can be implemented for any specific architecture.

It's more subtle than that.  The address arithmetic is related to the
size but it need not be exactly as you describe.

-- 
Ben.

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

#14688

ralph wrote:
> 
> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:

> >explain, eventually, that arr[i] is, by definition, *(arr + i).
> >
> 
> Sure it is because it ain't *(arr + i). It is ...
> 
> *(arr + ( i * sizeof(datatype)))

Ben Bacarisse is right.
ralph is wrong.

ISO/IEC 9899

6.5.2.1 Array subscripting

Semantics

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

-- 
pete

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

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

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

csiph-web