1

I want to know the Difference between below four terms in C/C++:

  1. p[i]

  2. i[p]

  3. *(p+i)

  4. *(i+p)

Where p is Array, i is loop current index.

Jaydeep Pandya
  • 825
  • 1
  • 10
  • 25

4 Answers4

7

p[i] is equivalent to *(p+i), as per the standard definition. Because addition is commutative, *(p+i) is the same as *(i+p). And as per the rule previously stated, *(i+p) is equivalent to i[p].

So, they are all the same.

Note that this only applies to built-in operators (i.e. operators applied to built-in types). User defined operators (both [] and +) do not have to follow these rules.

Benjamin Lindley
  • 101,917
  • 9
  • 204
  • 274
  • 1
    _"Because addition is commutative"_ it's not really an explanation for this, I would say that is because the way _pointer arithmetic_ works; the addition itself it's part of an expression but doesn't really explain what's going on. – user2485710 Jan 27 '14 at 05:32
  • 2
    @user2485710 It explains exactly what is going on. It is a mathematical operation (addition). Order of operands does not matter for addition. – Zac Howland Jan 27 '14 at 05:34
  • @ZacHowland nope, think about removing the addition and putting a multiplication in it. it's just a math operation with no special meaning, it's not the core of what it's happening nor it's part of a good explanation. – user2485710 Jan 27 '14 at 05:36
  • 2
    @user2485710: *"I would say that is because the way pointer arithmetic works"* -- And I would say *that* doesn't explain anything. I stand by my answer as a correct explanation of what is going on. – Benjamin Lindley Jan 27 '14 at 05:40
  • @user2485710 Whether it is addition or multiplication, it matters not. For this question, it is addition, and it is the same for all 4 ways described in the OP's question - and yes, it **is** the core of what is happening. – Zac Howland Jan 27 '14 at 05:40
  • I still think that programming is different from _math 101_ – user2485710 Jan 27 '14 at 05:56
2
  1. This accesses the (i + 1)-th element of an array pointed to by p. This can either be a static array or a dynamic array - in either case, p points to the first element (0).
  2. This is a bad way to write the same thing and should never be used in real code. It would result in treating i as a pointer to an array and p as an index. Mathematically, it would work out to the be the same memory location, but as written, I would be surprised if it compiles (though, it does as shown in the example - but it is still a poor way to structure code as it goes against the normal convention).
  3. This is the same as #1
  4. Also the same as #1

You can see them all here

Zac Howland
  • 15,777
  • 1
  • 26
  • 42
  • The second one is actually adding the value of p (address of array) to the integer i, right?. – sajas Jan 27 '14 at 05:28
  • Honestly, The idea that `p[i] = *(p+i)` always confuses me. what if `sizeof(*p)` is something large like `64`? I always thought that `p[i] = *(p + i*sizeof(*p))` – chbaker0 Jan 27 '14 at 05:28
  • @sajas Yes, it would be dereferencing an array `i` at offset `p` (which works out to the correct memory location mathematically - and compiles with gcc, surprisingly). – Zac Howland Jan 27 '14 at 05:30
  • #point 2 -> Yes it is compiling successfully...And return same result as p[i]. – Jaydeep Pandya Jan 27 '14 at 05:30
  • @mebob The sizeof is implied with the arithmetic. – Zac Howland Jan 27 '14 at 05:30
  • @ZacHowland Ah, that is the missing link for me. Is the same true for C? Or just C++? What could I do to get just a plain byte offset, if I ever needed one? – chbaker0 Jan 27 '14 at 05:32
  • @Zac, there is no array `i` in this scenario, and it should come as no surprise that GCC (or any other C compiler) accepts it, given it's perfectly valid C code. – Rob Kennedy Jan 27 '14 at 05:33
  • @mebob Yes, this is the same for C. – Zac Howland Jan 27 '14 at 05:35
  • @RobKennedy I did not state it was invalid, just that it was a poor way to write it. And given that the type for `i` is `int`, and not `int[]` or `int*`, it is kind of surprising that a strongly typed language doesn't complain about it (even though the math works out either way). – Zac Howland Jan 27 '14 at 05:36
  • I feel like such a moron. I've wasted so much time writing the `i*sizeof(...)` statement in the past. – chbaker0 Jan 27 '14 at 05:38
  • I didn't mean to suggest you thought it was invalid. But why would you be surprised that a C compiler accepts C code? Did you instead mean to express surprise that the standards *said* it was valid in the first place? That's more understandable. I don't think it was constructed as a primary goal, though. Rather, it was a natural consequence of the other rules (expansion of bracket notation, and commutativity of addition), and wasn't worth expressly disallowing. – Rob Kennedy Jan 27 '14 at 05:46
  • @RobKennedy "Did you instead mean to express surprise that the standards said it was valid in the first place?" <-- Yes. Though, I understand why it is allowed when it is converted to the dereferencing notation, it still is rather odd looking. – Zac Howland Jan 27 '14 at 14:13
0

p[i] means you are access the i+1 th element of the array p.

*(p+i) means you are defining a pointer *p, and accessing the contents of a memory location away from p by i times the size of the data that p points to.

(Again this means the same in case of array p[i], just adding the additional meaning to this when explicitly using pointer).

Assume that p is a pointer to int and that size of int is 4 bytes, then p+i points to a memory location x +4*i. where x is the memory location pointed to by p. Hence *(p+i) is used to access the contents of that memory location.

EDIT: and i[p] and*(i+p) is the same as p[i] (as I learnt just now) :)

SoulRayder
  • 5,072
  • 6
  • 47
  • 93
0

You declare an Array arr[n],

  1. arr ---> base address of the array and n is the offset.
  2. arr[n] ---> accessing the nth element from the array or better n offset from the base address
  3. *(arr + n) == *(n + arr) adding n offset to the base address to get the element.
  4. n[arr] == just another way of accessing the array , "associative property"
Ansh David
  • 654
  • 1
  • 10
  • 26