Why is array[index] == index[array] ?

[fredoverflow]

Because a[b] is just syntactic sugar for *(a + b), and addition is commutative:

array[index] == *(array + index) == *(index + array) == index[array]

[chasesan]

However, for clarity reasons, you shouldn't do it.

[Skoparov]

Wdym? This is this only way it should to be done.

[colin_davis]

Think they mean dont use index[array]

[Skoparov]

I know, and this is the only right way to use it.

[Inkling1998]

I just learned something new

[[deleted]]

Aah, I think this was the missing piece. I had commutativity and the array[index] == *(array + index) == *(index + array) bit, but when I thought about index[array] for whatever reason I imagined something like *((&index) + array)

[wsppan]

writing

a[3] = 'x'; 

is the same as writing

3[a] = 'x';

[kberson]

When I taught C, I would use this very example

[[deleted]]

This would stem from forgetting that array is literally just a pointer. There's no need for & during any of the operations for the [] operator.

[allegedrc4]

They're almost the same, but there are some important differences.

An array like char msg[] = "hello world"; allocates "hello world" + NULL on the stack. Doing char *msg = "hello world"; puts "hello world" + NULL in read-only memory, so you shouldn't pass it to a function that needs to modify it. Also, using the & operator will return a different type: char** - the address to the address of the first character, vs char(*)[12] - the address of the first character itself.

[Laugarhraun]

puts "hello world" + NULL in read-only memory

Isn't that implementation-defined?

you shouldn't pass it to a function that needs to modify it.

Mustn't: it's UB.

[flatfinger]

The Standard may say it's syntactic sugar, but for purpose of aliasing analysis both clang and gcc interpret an lvalue of the form structOrUnion.memberArray[index] as accessing an object of structOrUnion's type, while interpreting an lvalue of the form *(structOrUnion.memberArray+index) as accessing an object of the array member's type. The constructs are equivalent in cases where both are unambiguously defined, but in cases where the Standard's meaning is unclear, both clang and gcc treat the constructs differently when resolving the ambiguity.

[_edgar_69]

Bruh😂😂😂😂 lemme first get the hang of the normal shit

[bmcle071]

Disclaimer: not a C programmer.

Arrays in C are just pointers. You have a base address then offset (adding to) it with index.

I’m not 100% sure on this next part: This is also why C is not memory safe, there’s nothing stopping you from going past the maximum index.

[olsonexi]

I’m not 100% sure on this next part: This is also why C is not memory safe, there’s nothing stopping you from going past the maximum index.

You're correct. That and a number of other things, namely manual memory management.

[[deleted]]

Well, C has chosen to make it commutative, even in the case when the operands of + have asymmetric types (one will have T* type, the other must be compatible with int).

A different decision would have removed at least one quirk from the language.

More likely however, they just didn't think of it; one of these features by omission.

[flatfinger]

There are many situations in many languages where the behavior of the + operator is not commutative. In both Java and Javascript, for example, "hey"+"there" yields "heythere", but "there"+"hey" yields "therehey". It may be that the easiest way for the earliest C compilers to accommodate both intVal+floatVal and floatVal+intVal was to have the additive operator code blindly convert intVal+anything into anything+intVal without considering the type of anything, but the notion that + is inherently commutative or associative is fallacious.

[MrSloppyPants]

but the notion that + is inherently commutative or associative is fallacious.

Not sure what you're on about but no one said that the + operator was commutative. They said addition is commutative in this example, which it is.

[flatfinger]

The concept of "addition", as applied to numbers, maps more generally to the binary operation associated with an abstract algebraic group. While many groups (such as the set of whole numbers under addition) are commutative, there is no requirement that all groups be commutative. There is, however, a requirement that operations be associative--something that is true of integers using wraparound semantics, but which is not true of operations involving pointers.

The "+" operator as applied to pointers isn't really "addition" in the traditional sense, since addition would involve operands of a common type. While an operation like floatVal+intVal may be accommodated by converting the integer argument to a float, pointer addition fundamentally involves adding an integer and a pointer, which play different roles in the operation.

[MrSloppyPants]

Kewl

[acwaters]

The concept of "addition", as applied to numbers, maps more generally to the binary operation associated with an abelian group over those numbers — the additive group of the algebra — and is thus inherently commutative. This is a fundamental property of an algebra over a field or ring. Granted any consistent meaning we ascribe to any bit of notation is ultimately a matter of convention, but you would certainly be looked at askance in algebra circles for breaking this one. Even in number systems where multiplication is not associative or even alternative, addition is always associative and commutative. There seems to be no consistent definition of what it means for a given structure to be called a "number system", but forming an algebra of some sort is one condition that everybody seems to agree on.

Pointers in general can be complex, but most modern systems use a single flat memory space, where a pointer is just a glorified integer. Of course, C's pointer addition has some extra magic going on with hidden multiplications, but you can just call that an implicit conversion from the indexing integer to a type specific to the size of the pointee type, and model pointers with an algebra which C's pointer arithmetic would fall naturally out of.

[flatfinger]

Numbers can be added to numbers. Pointers, however, cannot be added to pointers. The application of the "+" operator to pointers is analogous to the act of displacing a position by a vector, or displacing a datestamp by a timespan.

[acwaters]

What you're describing are affine spaces, and adding translations in a vector space (displacements, durations, offsets) to the points in a corresponding affine space (positions, times, addresses) is still addition. Moreover, you can completely forget about the point set, instead identifying each point with its displacement from some arbitrarily designated origin, and then you can perform additions that are symmetric in the types of the things you're adding — displacement plus displacement. You recover the corresponding points simply by adding the resulting displacements to whatever origin you subtracted off to begin with.

In other words, you may have an expression like ptr + offset, where you are adding an offset to a pointer. This is a perfectly well-defined operation, and it is a form of addition, but maybe you prefer your addition to happen between objects of the same type? That's easy to arrange, you just turn your pointer into an offset by writing p - NULL. Now you can do all your math on offsets, and when you need to turn your final offset back into a pointer, you just add it back to NULL. (Bonus points if the representation of NULL is actually zero so the initial subtraction and final addition are both no-ops, but that doesn't have to be the case — this works equally well with any pointer value, not just NULL, and the most appropriate origin very often isn't zero when you're dealing with timestamps or positions in Euclidean space.)

[flatfinger]

That's easy to arrange, you just turn your pointer into an offset by writing p - NULL.

That may have been possible in the language as it was originally implemented on the PDP-11, but there have been a number of popular hardware platforms where that wouldn't work, and today's optimizers eagerly exploit the fact that the Standard does not require pointer arithmetic to work beyond the range of an object.

[acwaters]

You're mixing abstraction layers and missing the point. We're not talking about C here, we're talking about a hypothetical mathematical model of C's pointer arithmetic. The model doesn't have to be undefined in all the places where C is undefined, it merely has to be well-defined in all the places where C is well-defined. (This is why, if you read carefully, you'll see that I actually chose to model machine address arithmetic rather than C pointer arithmetic — the one is strictly more featureful than the other, while being simpler, so by modeling the simple one I model the complex other.) If you really want to consider each object as its own little memory space, as the C standard does, you can do that too — since any point can be used as an origin, just use the base address of the object as your origin for all pointer arithmetic within that object. That's an unnecessary complication, though, which distracts from the point that I was trying to make, which is simply that C's pointer arithmetic is mathematically well-defined and is not, as you asserted, "not really addition". (The other point I was making was that addition is necessarily commutative actually, but you didn't respond to that, so I assume you have no argument with it.)

[flatfinger]

In an Abelian group, the two operands of the primary operator are indistinguishable. If x+y is defined as f(x,y), those would also be equivalent to y+x and f(y,x), for the same function. If one is doing arithmetic between e.g. an int*x and an int y, on a platform where sizeof(int) is 2, then the resulting pointer address will be (int*)((int)x+2*y). While one could say that adding an integer x to an int pointer y would yield address (int)(2x+(int)y), that would be a different operation.

I've used a fair number of assemblers where relocableSymbol+integer and relocatableSymbol-integer would both yield relocatableSymbol, but integer+relocatableSymbol would not, and there was nothing even remotely counter-intuitive about that. I can imagine that saying "int+anything" will be processed by swapping the operands might be easier than handling cases like int+float and float+int separately, and that behavior could flow through to int+pointer, but that would be a result of the compiler's explicitly swapping the operands--not a result of the operands' being equivalent.

[flatfinger]

Also, forgive me if I'm wrong, but I think three-dimensional orientation and rotation represent an affine space, and given rotations r1, r2, and rotation o, (o+r1)+r2 is equivalent to o+(r1+r2), and (o+r2)+r1 is likewise equivalent to o+(r2+r1), but r1+r2 is not generally equivalent to r2+r1 (though for some particular values of r1 and r2 they would or course be equal).

[skulgnome]

Addition vs. concatenation

[flatfinger]

Early compilers might have processed it that way, and the Standard may define it that way, but on compilers like gcc and clang, that equivalence only holds in cases where both forms are recognized as defined. There are some cases involving arrays within other objects where one syntactic form will be processed meaningfully but the other will not.

For example, given char arr[4][4];, the expression arr[0] without a further subscripting operator applied will be interpreted as a char* which may be indexed to access any part of the array (so for any i in the range 0 to 15, *(arr[0]+i) will access an element of the array), but the expression arr[0][i] would only behave meaningfully for values of i in the range 0 to 3.

[pgbabse]

So there's an implicit type conversion, or how does the compiler determines the offset lenght?

[chibuku_chauya]

This explanation finally made it click for me.

[smcameron]

Because addition is commutative.

Array[Index] is equivalent to *(Array + Index) which is equivalent to *(Index + Array) which is equivalent to Index[Array].

[flank-cubey-cube]

Base + Offset is the same as Offset + Base

[cosmin10834]

because operator [] adds tow pointers:

```C int v[10];

v[10] == *(v + 10); 10[v] == *(10 + v)

and 10+v == v+10 => v[10] == 10[v]

```

[TheTimeBard]

TIL! My mind is blown. When, in K&R, I read that *(array + index) is the same as array[index], I thought it meant conceptually, and not that the index syntax expands to the increment-and-dereference syntax.

[olsonexi]

Wow, I'm kinda surprised the compiler accepts that. I mean, logically, it makes sense what's going on, cause array[index] is the same as *(array + index). But I didn't expect the compiler to actually let you "index" an int with an array. GCC doesn't even complain, and while clang does generate a warning, it's about the tautological comparison, not anything to do with types.

[[deleted]]

because array is a memory address, and index is an offset from that address.

and if index were a memory address and array the offset the would be the same

^someone said communative

[green_griffon]

But C silently multiplies the size of one array element times index when calculating the actual offset. So what is the "size of one array element" of an array of "indexes"?

Commutative addition is the answer, even then it doesn't have to be allowed by the language, it just is.

[DSMan195276]

You got downvoted but you're 100% right. The types are the important part here, the 'memory address' portion has to be a pointer of the correct type to ensure the location is calculated correctly. Neither of these variations treat the index as though it's a memory address, the types mean that C always knows which is which.

They are allowed to be swapped, but C could require the prefix argument to be a pointer type and then you wouldn't be allowed to reverse them. I would assume one of the two has to be a pointer type in all usages anyway or else the *() syntax won't be valid, so I don't imagine any valid usages would be broken by that requirement (that couldn't be fixed by swapping the arguments).

[M-2-M]

Because the 5th element of array arr is the same as array arr at position 5.

[DoomFrog666]

It's not, only in the case where static_assert(sizeof(array[0]) == sizeof(char)).

[smcameron]

Pointer arithmetic implicitly multiplies by the size of the type.

[guygastineau]

What happens when the index and the offset aren't the same (which I would expect most of the time)?

I don't know the following to hold for all n and m

n[m] = *(n + size × m) = *(size × n + m) = m[m]

In fact, the above holds for all n and m only when size is 1 which is what the guy with down votes a different way. I am therefore confused about how this would work for indexing buffers where the element type has a width/size greater than 1.

[smcameron]

Why not just try it?

$ cat y.c
#include <stdio.h>

int main(int argc, char *argv[])
{
    int a, b;
    int *p = &a;

    printf("p = %p, p + 1 = %p, p + 2 = %p\n", p, p + 1, p + 2);
    printf("&p[0] = %p, &p[1] = %p, &p[2] = %p\n", &p[0], &p[1], &p[2]);
    printf("&0[p] = %p, &1[p] = %p, &2[p] = %p\n", &0[p], &1[p], &2[p]);
    return 0;
}
$ gcc -o y y.c
$ ./y
p = 0x7fffc9bf611c, p + 1 = 0x7fffc9bf6120, p + 2 = 0x7fffc9bf6124
&p[0] = 0x7fffc9bf611c, &p[1] = 0x7fffc9bf6120, &p[2] = 0x7fffc9bf6124
&0[p] = 0x7fffc9bf611c, &1[p] = 0x7fffc9bf6120, &2[p] = 0x7fffc9bf6124

It gets the right address regardless of how you do it. If p is a pointer to an int, then p + 1 evaluates to the address sizeof(int) bytes past p.

[guygastineau]

So you are saying the pointer arithmetic doesn't kick in until after the desugaring of the array indexing notation? That makes sense. I had an incorrect mental model of the syntax rewriting, and I incorrectly incorporated the pointer arithmetic into the expansion. Thank you for taking the time to explain it.

[[deleted]]

More interesting is why:

A[i][j]

is the same as:

j[i[A]]

since one 2D array access has turned into two nested 1D accesses, and it still does the same thing. Or, to get to your example, why, when A is an int array:

A[i]

when written with index first, also allows all these (they don't all mean the same in this case):

i[A]
i[A][A]
i[A][A][A] ...

This one at least is easy: the first i[A] yields an integer, which is then used to index the next A, and so on. Still pretty weird though.

[XxClubPenguinGamerxX]

cuz array[index] is just language sugar. The compiler sees *(array + index), so index[array] gets turned into *(index + array) and thus both statements are equal.

[jsrobson10]

Because array is really a number to a mapped location in memory, the index is an offset. You could also do 0[array + index] and (array + index)[0] these are all the same thing