On Mar 7, 1:45=A0am, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:
> On Sat, 6 Mar 2010 02:01:30 -0800 (PST)
>
> Quadibloc <jsav...@ecn.ab.ca> wrote:
> > The 2[a] syntax actually *works* in C the way it was described? I am
> > astonished. I would expect it to yield the contents of the memory
> > location a+&2 assuming that &2 can be persuaded to yield up the
> > location where the value of the constant "2" is stored.
>
> =A0 =A0 =A0 =A0 Yes of course it does - why else would I have mentioned i=
t in my
> first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a]
> is the same as a[2] is the same as *(a+2) and the rules for adding pointe=
rs
> and integers are well defined in C. This is the heart of my original poin=
t,
> array notation in C is syntactic sugar for pointer arithmetic (and also
> for allocation which I neglected to mention in my original post).

If a[2] was the same as *(a+2), then, indeed, since addition is
commutative, it would make sense that 2[a], being the same as *(2+a),
would be the same.

But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the
same as *(&2+a).

Unless in *(a+2) "a" suddenly stops meaning what I would expect it to
mean. In that case, C has considerably more profound problems than not
having arrays.

John Savard

On Sun, 07 Mar 2010 07:48:01 -0500
Greg Menke <g...@comcast.net> wrote:

> 
> Ahem A Rivet's Shot <s...@eircom.net> writes:
> 
> > On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
> > Quadibloc <j...@ecn.ab.ca> wrote:
> >
> >> On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> >> 
> >> >         No but x = *(y + 3) will store in x the contents of the
> >> > memory location at 3 + the value of y just as x = y[3] will and x = 3
> >> > [y] will, which is what I stated. You missed out the all important *
> >> > and ()s.
> >> 
> >> Intentionally. My point was that, while there is _some_ truth to the
> >> claim that C arrays tread rather lightly on the ground of hardware
> >> addressing, the claim that C doesn't have arrays at all, and the C
> >> array subscript operator does nothing at all but add two addresses
> >> together... is not *quite* true.
> >
> > 	The C subscript operator does do nothing other than adding two
> > numbers and dereferencing the result, that last action is rather
> > important. The validity of constructs like 2[a] and *(2+a) make this
> > clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
> > where a is a pointer.
> 
> Yet when dereferencing arrays of rank >= 2, dimensions are automatically
> incorporated into the effective address, so its not quite equivalent to
> a simple addition of pointer and offset.

	There is a way to regard it as such - consider a[x][y] as being
equivalent to *(a[x] + y) where we regard a[x] as devolving into a pointer
to a row of the array. But yes multidimensional array support is a little
more involved than single dimensional array support. It's still not a
proper type though.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Sun, 7 Mar 2010 05:35:51 -0800 (PST)
Quadibloc <j...@ecn.ab.ca> wrote:

> On Mar 7, 1:45 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> > On Sat, 6 Mar 2010 02:01:30 -0800 (PST)
> >
> > Quadibloc <jsav...@ecn.ab.ca> wrote:
> > > The 2[a] syntax actually *works* in C the way it was described? I am
> > > astonished. I would expect it to yield the contents of the memory
> > > location a+&2 assuming that &2 can be persuaded to yield up the
> > > location where the value of the constant "2" is stored.
> >
> >         Yes of course it does - why else would I have mentioned it in my
> > first post in this threadlet ? a is a pointer, 2 is in a integer and 2
> > [a] is the same as a[2] is the same as *(a+2) and the rules for adding
> > pointers and integers are well defined in C. This is the heart of my
> > original point, array notation in C is syntactic sugar for pointer
> > arithmetic (and also for allocation which I neglected to mention in my
> > original post).
> 
> If a[2] was the same as *(a+2), then, indeed, since addition is

	Which it is by definition.

> commutative, it would make sense that 2[a], being the same as *(2+a),
> would be the same.
> 
> But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the
> same as *(&2+a).

	No it's not - a in this context is treated as a pointer.

> Unless in *(a+2) "a" suddenly stops meaning what I would expect it to
> mean.

	Well I think you'll find a never die mean as what you would
expect it to mean. In many contexts including this one (and a[2] and 2[a]
and a + 2 or even (a+2)[3]) it is a pointer not an array - the only context
in which it is an array is the declaration.

> In that case, C has considerably more profound problems than not
> having arrays.

	C is consistent it's just that the array syntax really is a thin
mask for pointer arithmetic - even the multidimensional array syntax but
that's more fiddly.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Mar 7, 7:39=A0am, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:

> =A0 =A0 =A0 =A0 Well I think you'll find a never die mean as what you wou=
ld
> expect it to mean. In many contexts including this one (and a[2] and 2[a]
> and a + 2 or even (a+2)[3]) it is a pointer not an array - the only conte=
xt
> in which it is an array is the declaration.

Yes: the array name always refers to the pointer, and the subscript is
required to reference, not just to displace. That was my mistake; a
never did mean the "array" in the abstract sense... so that a "new,
improved" C copying Fortran 90 (or PL/I) could have statements like

int a[5],b[5] ;
...
b =3D a + 2 ;

and the compiler just makes

int a[5],b[5]
...
for (i00001 =3D 0; i++; i<5 )
 { b[i00001] =3D a[i00001] + 2
 } ;

out of it.

John Savard

On Sun, 7 Mar 2010 09:54:04 -0800 (PST)
Quadibloc <j...@ecn.ab.ca> wrote:

> On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> 
> >         Well I think you'll find a never die mean as what you would
> > expect it to mean. In many contexts including this one (and a[2] and 2
> > [a] and a + 2 or even (a+2)[3]) it is a pointer not an array - the only
> > context in which it is an array is the declaration.
> 
> Yes: the array name always refers to the pointer, and the subscript is
> required to reference, not just to displace. That was my mistake; a
> never did mean the "array" in the abstract sense... so that a "new,
> improved" C copying Fortran 90 (or PL/I) could have statements like
> 
> int a[5],b[5] ;
> ...
> b = a + 2 ;
> 
> and the compiler just makes
> 
> int a[5],b[5]
> ...
> for (i00001 = 0; i++; i<5 )
>  { b[i00001] = a[i00001] + 2
>  } ;

	Yes that would be nice, especially if it extended to full blown matrix
artihmetic.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

In article
<2...@eircom.net>,
Ahem A Rivet's Shot  <s...@eircom.net> wrote:
>On Sun, 07 Mar 2010 07:48:01 -0500
>Greg Menke <g...@comcast.net> wrote:
>
>> 
>> Ahem A Rivet's Shot <s...@eircom.net> writes:
>> > 	The C subscript operator does do nothing other than adding two
>> > numbers and dereferencing the result, that last action is rather
>> > important. The validity of constructs like 2[a] and *(2+a) make this
>> > clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
>> > where a is a pointer.
>> 
>> Yet when dereferencing arrays of rank >= 2, dimensions are automatically
>> incorporated into the effective address, so its not quite equivalent to
>> a simple addition of pointer and offset.
>
>	There is a way to regard it as such - consider a[x][y] as being
>equivalent to *(a[x] + y) where we regard a[x] as devolving into a pointer
>to a row of the array. But yes multidimensional array support is a little
>more involved than single dimensional array support. It's still not a
>proper type though.

That's all very well, but in fact no C implementation of which I am
aware uses dope vectors when allocating multidimensional arrays. (I
have come across the practice in other languages).  In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.

In comp.arch.fpga John Francis
<j...@panix.com> wrote:
(snip)
 
> That's all very well, but in fact no C implementation of which I am
> aware uses dope vectors when allocating multidimensional arrays. (I
> have come across the practice in other languages).  In fact C has to
> perform different calculations to evaluate the address of an element
> a[i][j], depending on how a was defined (int a[4][5], or int** a).
> The sizeof operator also knows something about array types.

VMS compilers are supposed to allow for value, reference, or 
descriptor argument passing to support interlanguage calls.
The %val(), %ref(), and %descr() syntax is supposed to be
supported by all compilers.

-- glen

On Mar 7, 11:09=A0am, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:
> On Sun, 7 Mar 2010 09:54:04 -0800 (PST)
>
>
>
> Quadibloc <jsav...@ecn.ab.ca> wrote:
> > On Mar 7, 7:39=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> > > =A0 =A0 =A0 =A0 Well I think you'll find a never die mean as what you=
 would
> > > expect it to mean. In many contexts including this one (and a[2] and =
2
> > > [a] and a + 2 or even (a+2)[3]) it is a pointer not an array - the on=
ly
> > > context in which it is an array is the declaration.
>
> > Yes: the array name always refers to the pointer, and the subscript is
> > required to reference, not just to displace. That was my mistake; a
> > never did mean the "array" in the abstract sense... so that a
"new,
> > improved" C copying Fortran 90 (or PL/I) could have statements like
>
> > int a[5],b[5] ;
> > ...
> > b =3D a + 2 ;
>
> > and the compiler just makes
>
> > int a[5],b[5]
> > ...
> > for (i00001 =3D 0; i++; i<5 )
> > =A0{ b[i00001] =3D a[i00001] + 2
> > =A0} ;
>
> =A0 =A0 =A0 =A0 Yes that would be nice, especially if it extended to full=
 blown matrix
> artihmetic.

To avoid confusion, it is probably better if multiplying two two-
dimensional arrays produces element-by-element multiplication - and,
to get matrix multiplication, you need to declare variables having a
MATRIX type, analogous to the COMPLEX type.

John Savard

On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
j...@panix.com (John Francis) wrote:

> In article <2...@eircom.net>,
> Ahem A Rivet's Shot  <s...@eircom.net> wrote:
> >On Sun, 07 Mar 2010 07:48:01 -0500
> >Greg Menke <g...@comcast.net> wrote:
> >
> >> 
> >> Ahem A Rivet's Shot <s...@eircom.net> writes:
> >> > 	The C subscript operator does do nothing other than adding
> >> > two numbers and dereferencing the result, that last action is rather
> >> > important. The validity of constructs like 2[a] and *(2+a) make this
> >> > clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
> >> > where a is a pointer.
> >> 
> >> Yet when dereferencing arrays of rank >= 2, dimensions are
> >> automatically incorporated into the effective address, so its not
> >> quite equivalent to a simple addition of pointer and offset.
> >
> >	There is a way to regard it as such - consider a[x][y] as being
> >equivalent to *(a[x] + y) where we regard a[x] as devolving into a
> >pointer to a row of the array. But yes multidimensional array support is
> >a little more involved than single dimensional array support. It's still
> >not a proper type though.
> 
> That's all very well, but in fact no C implementation of which I am
> aware uses dope vectors when allocating multidimensional arrays. (I

	Indeed they don't - it is simply a matter of how you interpret the
partial construct a[x] when a is declared as a two dimensional array - one
way of interpreting it is as a pointer to an array row even though it is
not a valid construct on it's own.

	There is a clear extension of the one dimentsional case a declaration
int a[5] leaves future references to a as being equivalent to &(a[0]) so
it is reasonable to regard a declaration int a[4][5] as leaving future
references like a[i] as equivalent to &(a[i][0]).

> have come across the practice in other languages).  In fact C has to
> perform different calculations to evaluate the address of an element
> a[i][j], depending on how a was defined (int a[4][5], or int** a).
> The sizeof operator also knows something about array types.

	If a is defined as int **a then a[i][j] is not valid at all.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

Ahem A Rivet's Shot wrote:
> On Sun, 7 Mar 2010 09:54:04 -0800 (PST)
> Quadibloc <j...@ecn.ab.ca> wrote:
> 
>> On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>
>>>         Well I think you'll find a never die mean as what you would
>>> expect it to mean. In many contexts including this one (and a[2] and 2
>>> [a] and a + 2 or even (a+2)[3]) it is a pointer not an array - the only
>>> context in which it is an array is the declaration.
>> Yes: the array name always refers to the pointer, and the subscript is
>> required to reference, not just to displace. That was my mistake; a
>> never did mean the "array" in the abstract sense... so that a
"new,
>> improved" C copying Fortran 90 (or PL/I) could have statements like
>>
>> int a[5],b[5] ;
>> ...
>> b = a + 2 ;
>>
>> and the compiler just makes
>>
>> int a[5],b[5]
>> ...
>> for (i00001 = 0; i++; i<5 )
>>  { b[i00001] = a[i00001] + 2
>>  } ;
> 
> 	Yes that would be nice, especially if it extended to full blown matrix
> artihmetic.
> 

Sure, just use PL/I ;-)