Accessing array by pointers

Question

let int * ptr,array[10]; ptr= array;. Now each of the memory cells in array's contiguous locations have a fixed size. If the address of first cell is 1234 then the next cell must be at 1238 address. But we access it using a pointer as *(ptr+1). I am confused regarding this. Any sources or answers? Thanks.

Pointers know the type (and therefore size) of the thing they point to (except when they don't, but then this is illegal...). `ptr+1` changes the actual numeric value behind the pointer by the size of the pointed to object. — BoBTFish, Aug 02 '13 at 15:12
Pointers arithmetics http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html — Nbr44, Aug 02 '13 at 15:12
`*(ptr+1)` it's what can be called as a "logical operation" it's a `+1` from a logical point of view. — user2485710, Aug 02 '13 at 15:13
that's just how pointer arithmetic works. If you create an array of MyBigObject, you can take a pointer to the start of the array, and when you increment the pointer the memory address will increase by sizeof(MyBigObject) — Graham Griffiths, Aug 02 '13 at 15:13
possible duplicate of [Pointer Arithmetic](http://stackoverflow.com/questions/394767/pointer-arithmetic) — , Aug 02 '13 at 15:22
Does it actually say in the standard that arrays must be contiguous in memory? It says that `a[i]` must be equivalent to `*(a+i)`, so if the implementation changes how `+` works with pointers (which as mentioned it does anyway) I don't think it has to keep data contiguous. — Matt, Aug 02 '13 at 15:22
@Matt: It must be contiguous in the C memory model. C 2011 (N1570) 6.2.5 20: “An array type describes a contiguously allocated nonempty set of objects…”. Of course, it does not need to be contiguous in the virtual address space (but usually is, in most C implementations) or in the physical address space of the machine (and is easily not contiguous, as the operating system allocates pages as it pleases). And, of course, the memory might not be physically contiguous as successive chunks of memory (by physical address) may be stored in different chips. — Eric Postpischil, Aug 02 '13 at 15:26
@EricPostpischil, yes it seems that the C++ standard I have says the same: "An object of array type contains a contiguously allocated non-empty set of N subobjects of type T." — Matt, Aug 02 '13 at 15:31
possible duplicate of [In C arrays why is this true? a\[5\] == 5\[a\]](http://stackoverflow.com/questions/381542/in-c-arrays-why-is-this-true-a5-5a) — Mgetz, Aug 02 '13 at 15:37

Mgetz · Answer 1 · 2013-08-02T15:34:39.433

From the C11 standard: §6.5.2.1

A postﬁx expression followed by an expression in square brackets [] is a subscripted designation of an element of an array object. The deﬁnition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))). Because of the conversion rules that apply to the binary + operator, if E1 is an array object (equivalently, a pointer to the initial element of an array object) and E2 is an integer, E1[E2] designates the E2-th element of E1 (counting from zero).

E.G. what you're doing is basically what [] already does

Also (same standard) explains why pointers increment as you noticed: §6.5.6

When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i−n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overﬂow; otherwise, the behavior is undeﬁned. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.

I think he was wondering why the +1 advances to 1238 instead of 1235. — Jiminion, Aug 02 '13 at 15:15

score 3 · Accepted Answer · answered Aug 02 '13 at 15:13

3

The compiler knows that ptr is a pointer to a 4-byte type, so it knows that ptr+1 is 4 bytes further on in the memory.

If you think for a moment, it's clear that this must be so, as otherwise you couldn't write portable code without knowing the size of (for instance) an integer on your system.

Further, array indexing is exactly pointer arithmetic under the covers - that is, array[3] is exactly the same as *(array + 3)

answered Aug 02 '13 at 15:13

Chowlett

45,935
20
116
150

You _could_ write portable code, by multiplying each advance by `sizeof(int)`. It would just be a lot more painful. – James Kanze Aug 02 '13 at 15:22
@Mgetz I'm not sure what you're referring to. I said nothing the standard; I was just commenting on Chowlett's point that with _different_ rules, you couldn't write portable code. You could, but boy would it be a pain (and error prone). – James Kanze Aug 02 '13 at 17:04

score 1 · Answer 3 · answered Aug 02 '13 at 15:13

1

When indexing a pointer, the compiler knows that the index should be advanced by the size of the cell, in this case, a pointer of 4 bytes.

answered Aug 02 '13 at 15:13

Jiminion

5,080
1
31
54

score 1 · Answer 4 · answered Aug 02 '13 at 15:15

1

Pointer arithmetic considers the size of the pointed type. For instance, if the value of ptr is 1234, since ptr is of type int*, then the value of p + 1 is 1234 + 1 * sizeof(int) == 1234 + 1 * 4 = 1238 (assuming sizeof(int) == 4).

answered Aug 02 '13 at 15:15

Cassio Neri

19,583
7
46
68

score 0 · Answer 5 · answered Aug 02 '13 at 15:17

0

The right operand of the + operator, lets call it x, is not the actual amount you're moving the pointer. Because int is 4 bytes, the compiler knows to actually skip to x*4.

answered Aug 02 '13 at 15:17

Jamey Diepbrink

61
6

score 0 · Answer 6 · answered Aug 02 '13 at 15:22

The units of pointer arithmetic are pointed-to objects, not bytes.

If p points to int objects, then p+1, p+2, and p+3 point to successive int objects, not to successive bytes. If p points to a large structure, then they point to successive instances of the structure.

The compiler does its work behind the scenes to convert the pointer arithmetic into machine address arithmetic. So it multiplies offsets as necessary to convert from units of objects to units of bytes.

score 0 · Answer 7 · answered Aug 02 '13 at 15:26

My guess is that according to you (ptr + 1) should give you 1235 but obviously it doesn't.

In addition to the answers given by others as to why it adds 4 and gives you 1238, consider the case if it gave you 1235, at 1235 you don't have an integer element(i.e. the 2nd element of the array). But your pointer should point to an integer . Hence it doesn't work out this way.

score 0 · Answer 8 · answered Aug 02 '13 at 15:31

Pointer arithmetic is a different operation than normal arithmetic. In Pointer arithmetic, one argument has to be a pointer type, the other one has to be an integral type:

intA + intB: Normal arithmetic, result is the sum.
intA + pointerB: Pointer arithmetic, the calculation performed is sizeof(*pointerB)*intA + pointerB
pointerA + intB: Pointer arithmetic, the calculation performed is pointerA + sizeof(*pointerA)*intB
pointerA + pointerB: Illegal

pointerA[intB] is just a shorthand for case 2 (pointerA + intB), which is why it is equivalent to intB[pointerA] (resolves to case 3), but that's only of use in the IOCCC.

Accessing array by pointers

8 Answers8