0

The question is not about what happens, but why it happens.

//for printf
#include <stdio.h>
//for malloc
#include <stdlib.h>

int main(void)
{
    int *pointy = malloc(4 * sizeof(int));
    pointy[0] = 22;
    pointy[1] = 23;
    pointy[2] = 24;
    printf("%p meow %i meow %p meow %p meow %p meow %p", pointy, sizeof(int), &(pointy[1]), (pointy + 1 * sizeof(int)), (pointy + 1), ((int)pointy + 1 * sizeof(int)));

    //deallocating the space
    free(pointy);
}

Output : 00000000000A1400 meow 4 meow 00000000000A1404 meow 00000000000A1410 meow 00000000000A1404 meow 00000000000A1404

So, pointy+1 adds 4 bytes to pointy. I guess that is because pointy is of type "int*" and the addition happens similar to the logic:

(int*) pointy + (int*) 1

But it isn't working the same way like adding an int to a double ( which would yield a double result). The compiler doesnt actually let me cast " 1 " to type " int * " if I try to do so in this scenario... So I think there are more reasons beneath it. And googling didn't work, so I'm asking it here.

Please provide a detailed explanation, and I'll be thankfull.

The lower-level explanation, the better. I also would like to learn if you have any recommendations on learning fundamentals of programming with a COMPLETE * bottom-up * approach

Batıkan Bora Ormancı
  • 31
  • 5
  • 4
    It works this way so that `arr[i] == *(arr + i)`. Pointer arithmetic is the same as indexing an array. – Barmar Jan 23 '20 at 17:45
  • 1
    A pointer + offset makes sense, but what would pointer + pointer actually represent? – jarmod Jan 23 '20 at 17:45
  • Array is "Syntactic sugar" for *(arr + i). What I would like to know is the reasoning beneath *(arr+i) – Batıkan Bora Ormancı Jan 23 '20 at 17:46
  • 1
    What reasoning do you want? Humans chose to make it this way. When you write an expression such as `p + i`, the compiler knows the type of `p`, it knows the size, it multiplies `i` by the size, and it adds that amount to the pointer. It all works that way because humans decided to do it and wrote the software to make it happen. And they wrote it into the C standard. There is no law of math or logic forcing it to happen that way. It is a matter of choice. – Eric Postpischil Jan 23 '20 at 17:49
  • At the instruction level, in a platform where addresses are “flat” (they are simply integers that number all the memory locations), adding a number to an address is implemented simply with a multiplication and an addition. Often those are combined into one instruction that does both. The hardware manufacturers provide instructions and instruction forms to assist this. – Eric Postpischil Jan 23 '20 at 17:51
  • The reason behind why pointer arithmetic works like it does is only that the C standard dictates it. Why? Because who wrote it decided like so. There is no other reason. It's a language design choice. – Marco Bonelli Jan 23 '20 at 17:55
  • @EricPostpischil Why can't I cast an int to (int *), but it automatically does that anyways.... Is this solved the same way other arithmetical complexities, if I may call them so, get solved in c ? '(double) 4 + (int) 5' would yield a result of type double, and I understand that, 5 can also be casted into double, and it is by the compiler ( I guess ). But this logic isn't exactly the same as in pointer arithmetics, or is it ? – Batıkan Bora Ormancı Jan 23 '20 at 17:57
  • You can very well cast an `int` to `(int*)`, whether it makes sense or not depends on context, but it's allowed. Casting is totally unrelated to the design choice of pointer arithmetic. – Marco Bonelli Jan 23 '20 at 17:59
  • @MarcoBonelli I'm sorry I tried it again and it seems I can do that... but the following is still now allowed: `printf("%i", (int *)1 + pointy);` because *** error: invalid operands to binary + (have 'int *' and 'int *') *** Two pointer-data-types (or pointer variables) (or pointers with the pointees of same type) can't be added to one another, which completely seperates this from all the other complex-data-type-arithmetics.... Thank you. – Batıkan Bora Ormancı Jan 23 '20 at 18:04
  • @BatıkanBoraOrmancı you're mixing so many different problems and concepts into a single comment thread that it really does not make sense to continue discussing. Treat each problem *separately*. That's all I have left to say. – Marco Bonelli Jan 23 '20 at 18:07

0 Answers0