0

What does [] do when called on an int* pointer?

E.g. in this code:

int* someIntPointer = 4000;     //pointer points to byte 4000 in memory
++someIntPointer;           //pointer points to byte 4004 in memory
someIntPointer[5];          //What memory spot does someIntPointer point to now?

And is it differnt when called on an char*?

It seems to me that calling eg [5] on an pointer increments the pointer by 5, so that it points to a memory spot (5 * the byte-size of the data-type) higher, so e.g. 20 (5*4) for int_32. Is that correct?

Regards and thanks for any answers

someuser47
  • 1
  • 1
  • Possibly a duplicate of https://stackoverflow.com/questions/4622461/difference-between-pointer-index-and-pointer – UnholySheep Apr 27 '23 at 12:06
  • Applied to a pointer `pointer[index]` it is *exactly* equivalent to (syntactic sugar for) `*(pointer + index)` – side note/funny fact: which actually leads to being equivalent to `*(index + pointer)` and finally to being equivalent to `index[pointer]`, thus making the weird-looking `7[pointer]` valid code doing the same... – Aconcagua Apr 27 '23 at 12:10
  • The pointed to type is irrelevant in this respect – apart from the distance in *bytes* being different (`&charPtr[1] - &charPtr[0]` – is always 1 while the analogous difference for `int` pointers is `sizeof(int)`). The distance in array units (i.e. pointed type) remains 1 for neighbouring elements. – Aconcagua Apr 27 '23 at 12:14
  • 1
    Note that pointer arithmetic is defined by the C standard **only** for addresses within an array, including the address pointing to the end of the array (just beyond the last element). C compilers may extend the arithmetic to work for arbitrary addresses, but you should check the compiler documentation before relying on that. – Eric Postpischil Apr 27 '23 at 12:16
  • ... though single objects, when pointed at, count in this respect as an array of size 1, i.e. the one-past-the-end-pointer – belonging to the same array – is valid even in this case (but cannot be dereferenced, just as with normal arrays). – Aconcagua Apr 27 '23 at 12:37
  • The code posted is invalid C. You cannot write things like `int* someIntPointer = 4000; ` in C. It does not compile cleanly. – Lundin Apr 27 '23 at 13:09

2 Answers2

0

yes, that's exactly the way it is handled, so you could easily (in some aspects) use a pointer as an array of whatever type the pointer points to.

Edit: as Aconcagua mentioned in comment:

Using a pointer as an array would fail for the famous sizeof-trick (sizeof(array)/sizeof(*array)

Synopsis
  • 190
  • 10
  • Uh... unlucky wording. Using a `pointer as an array` would fail for the famous `sizeof`-trick (`sizeof(array)/sizeof(*array)`... – Aconcagua Apr 27 '23 at 12:16
  • I anyway avoid sizeof(largerStructure) wherever I can. When size matters, it should be somehow switched to C++ using classes and largerStructure.sizeof() instead of sizeof(largerStructure). If not convertible, there should be well defined checks instead of a simple sizeof() – Synopsis Apr 27 '23 at 12:21
  • In C++ there's no general `sizeof()` function for any kind of larger structs or classes unless one explicitly defines it. Most standard containers provide a `size()` function, but that provides *entirely different* information to `sizeof` operator. Then finally there's `std::size` – the overload for arrays indeed replaces the `sizeof`-*trick* (i.e. `sizeof(array)/sizeof(*array)`, for containers, however, calls `size()`. It is *not* equivalent to `sizeof`, that still has its valid use cases (though nowadays rather in low level code, e.g. for manual memory management involving placement new). – Aconcagua Apr 27 '23 at 12:29
  • Not happy about your edit – your answer should be self-contained, i.e. especially not relying on comments to it. You might rather want to write explicitly that you are referring to the index operator exclusively – or best entirely reword. – Aconcagua Apr 27 '23 at 12:40
0

Applied to a pointer pointer[index] it is exactly equivalent to (so syntactic sugar for) *(pointer + index)

The pointed to type is irrelevant in this respect – apart from the distance in bytes being (usually) different ((uintptr_t)&charPtr[1] - (uintptr_t)&charPtr[0] – is always 1 while the analogous difference for int pointers is sizeof(int) – typically, but not necessarily 4). The distance in array units (i.e. the pointed at type) remains 1 for neighbouring elements, i.e. independent from type &pointer[1] - &pointer[0] == 1 (note the missing cast to uintptr_t).

Actually you don't even need an explicit index operator for arrays at all; applying the pointer index operator to an array would provoke the array decaying to a pointer anyway. If the C standard indeed relies on or still defines the array index operator separately I'm (currently) not aware of, though...

Side note/funny fact:

Above equivalence leads to the equivalence to *(index + pointer) and finally to index[pointer], making the weird-looking 7[pointer /* or array*/] valid code doing the same...

Aconcagua
  • 24,880
  • 4
  • 34
  • 59