From: Ahem A Rivet's Shot on
On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
johnf(a)panix.com (John Francis) wrote:

> In article <20100307143020.fcc7e3df.steveo(a)eircom.net>,
> Ahem A Rivet's Shot <steveo(a)eircom.net> wrote:
> >On Sun, 07 Mar 2010 07:48:01 -0500
> >Greg Menke <gusenet(a)comcast.net> wrote:
> >
> >>
> >> Ahem A Rivet's Shot <steveo(a)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/
From: John Francis on
In article <20100307214004.5b5fc8b4.steveo(a)eircom.net>,
Ahem A Rivet's Shot <steveo(a)eircom.net> wrote:
>On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
>johnf(a)panix.com (John Francis) wrote:
>
>> 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.

Rubbish. a[i][j] is a perfectly legal term in both cases I supplied,
and has a well-defined way of calculating the address.


From: Ahem A Rivet's Shot on
On Sun, 07 Mar 2010 20:11:53 -0600
Charles Richmond <frizzle(a)tx.rr.com> wrote:

> Ahem A Rivet's Shot wrote:
> > On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
> > Quadibloc <jsavard(a)ecn.ab.ca> wrote:
> >
> >> On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...(a)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.
> >
> > C does have good support for pointers and adding integers to
> > pointers and for declaring blocks of storage with an array like syntax.
> >
>
> ... but do *not* forget that when an integer is added to a
> pointer, that integer is "scaled" by the length associated with
> that pointer.

Yep *good* support for adding integers to pointers.

--
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/
From: Ahem A Rivet's Shot on
On Mon, 8 Mar 2010 07:45:53 +0000 (UTC)
johnf(a)panix.com (John Francis) wrote:

> In article <20100307214004.5b5fc8b4.steveo(a)eircom.net>,
> Ahem A Rivet's Shot <steveo(a)eircom.net> wrote:
> >On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
> >johnf(a)panix.com (John Francis) wrote:
> >
> >> 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.
>
> Rubbish. a[i][j] is a perfectly legal term in both cases I supplied,
> and has a well-defined way of calculating the address.

Er OK - you're right int **a is a pointer to a pointer to integers
so the first offset works in terms of sizeof(int *) and the second in terms
of sizeof(int).

--
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/
From: John Francis on
In article <20100308094342.f7fa8e54.steveo(a)eircom.net>,
Ahem A Rivet's Shot <steveo(a)eircom.net> wrote:
>On Mon, 8 Mar 2010 07:45:53 +0000 (UTC)
>johnf(a)panix.com (John Francis) wrote:
>
>> In article <20100307214004.5b5fc8b4.steveo(a)eircom.net>,
>> Ahem A Rivet's Shot <steveo(a)eircom.net> wrote:
>> >On Sun, 7 Mar 2010 18:59:43 +0000 (UTC)
>> >johnf(a)panix.com (John Francis) wrote:
>> >
>> >> 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.
>>
>> Rubbish. a[i][j] is a perfectly legal term in both cases I supplied,
>> and has a well-defined way of calculating the address.
>
> Er OK - you're right int **a is a pointer to a pointer to integers
>so the first offset works in terms of sizeof(int *) and the second in terms
>of sizeof(int).

True iff a is defined as int**.

Note that sizeof(a[n]) returns different values for the two declarations;
for the two-dimensional array the elements of a are not of type (int *);
they are of an anonymous datatype (a vector of 5 ints).