A seasoned C programmer knows that "&arr[index]" is really just "arr + index" :) So in a sense, the optimizer rewrote "x + y" into "(int)&(((char*)x)[y])", which looks scarier in C, I admit.

▲

crote 2 hours ago | parent [-]

The horrifying side effect of this is that "arr[idx]" is equal to "idx[arr]", so "5[arr]" is just as valid as "arr[5]".

Your colleagues would probably prefer if you forget this.

▲

miningape 2 hours ago | parent | next [-]

Mom, please come pick me up. These kids are scaring me.

▲

Joker_vD 2 hours ago | parent | prev | next [-]

> so "5[arr]" is just as valid as "arr[5]"

This is, I am sure, one of the stupid legacy reasons we still write "lr a0, 4(a1)" instead of more sensible "lr a0, a1[4]". The other one is that FORTRAN used round parentheses for both array access and function calls, so it stuck somehow.

▲

rocqua 2 hours ago | parent | prev [-]

That depends on sizeof(*arr) no?

▲

unwind 2 hours ago | parent | next [-]

Not in C no, since arithmetic on a pointer is implicitly scaled by the size of the value being pointed at (this statement is kind of breaking the abstraction ... oh well).

▲

messe an hour ago | parent | prev [-]

Nope, a[b] is equivalent to *(a + b) regardless of a and b.

▲

sureglymop an hour ago | parent [-]

Given that, why don't we use just `*(a + b)` everywhere?

Wouldn't that be more verbose and less confusing? (genuinely asking)

	▲	tomsmeding an hour ago \| parent [-]
		Do you really think that `*(a + i)` is clearer than `a[i]`?