array logic

[dev90]

int arr[]={12,17};
printf("\n arr = %d , &arr= %d",arr,&arr);

printf("\n arr+1 = %d , &arr + 1= %d",arr+1,&arr+1);

getch();
}

ans :
arr=400 &arr=400
arr+1=402 &arr+1=404

Please tell me how &arr and &arr+ 1 works?

[ss125]

Its the memory issue dude.

normally an integer datatype hold 2 byes of memory.If Int is declared it holds 2 bytes by default.

Same goes for array.

arr represents the data in the memory.

&arr represents the memory address of the variable arr.

arr + 1 which means 2 bytes.

&arr +1 means arr[]=> 2 bytes for arr and 2 bytes for array.

Further can be concluded from your answer.

Correct me if i am wrong in any case.

Have a happy coding.

[Gonbe]

normally an integer datatype hold 2 byes of memory.If Int is declared it holds 2 bytes by default.

This is not true. The amount of bytes an integer takes up depends on the supported word size of the used CPU and there is no "default" specified in the specification. 32-bit or 64-bit are most common on desktops and I've personally only encounter 8 and 16 bit integers on embedded systems.

&arr

This is a pretty common misconception. &arr represents the memory address of the first element in arr. (More precisely the memory address of the array, which is the memory address of the first element) and in this case that expression would be of type int(*)[2]. arr itself does not have a memory address. When used in an expression it is implicitly converted to a pointer type however, so int* in this case, representing the memory address of the first element in arr. Hence arr == &arr == &arr[0]. (the resulting memory addresses, the types of the expressions differ)

arr + 1 which means 2 bytes

As stated earlier arr would be implicitly converted to type int* so doing arr + 1 yields the memory address of the first element in arr (represented by arr) plus 1 time sizeof(int) amount of bytes. (represented by + 1) In this case this would be the memory address of the second element in arr.

&arr +1 means arr[]=> 2 bytes for arr and 2 bytes for array.

I'm not sure what you mean but I don't think this is right. &arr results in something of type int(*)[2]. (memory address of an integer array of size 2) Like above, adding 1 to the memory address results in incrementing the memory address with the amount of bytes taken up by the pointed to type. Instead of int above it is int[2] here. So the result would be the address of arr plus 2 * sizeof(int) bytes in this case.

[sepp2k]

arr itself does not have a memory address.

I wouldn't say it that way (you yourself refer to arr's address a couple of times in your post). Its address just happens to be the same as that of its first element.

So the result would be the address of arr plus 2 * sizeof(int) bytes in this case.

Or to make the mechanics a bit more obvious: the address of arr plus 1 * sizeof(int[2]). That is writing p + i where p is a T pointer (or array) always increments by i * sizeof(T) bytes - T in this case being int[2] and sizeof(Foo[N]) being equal to sizeof(Foo)*N for all types Foo.

[Gonbe]

I wouldn't say it that way (you yourself refer to arr's address a couple of times in your post). Its address just happens to be the same as that of its first element.

I wanted to make clear that arr does not contain the memory address of the array (because it would be a pointer then and &arr would be different from &arr[0]) but instead it is the memory address of the array (so that arr is the same as &arr[0] result-wise), if that makes sense. Terminology kind of gets confusing easily.. :< I helped some people in the past and it seemed to be an common thing that was misunderstood; arrays and pointers were used as the same thing. Often it doesn't lead to errors despite the misunderstanding, but sometimes it does. (I'd provide an example of it, but I don't have one handy right now)

Or to make the mechanics a bit more obvious: the address of arr plus 1 * sizeof(int[2]). That is writing p + i where p is a T pointer (or array) always increments by i * sizeof(T) bytes - T in this case being int[2] and sizeof(Foo[N]) being equal to sizeof(Foo)*N for all types Foo.

Hmm, that was kind of what I was trying to say but this makes it more clear I think yeah!

[dev90]

@ Gonbe :

No, I am not wrong in case of &arr+1. for more clarity try adding more elements in array and try to run it. Well. i've checked this code in TC.

Inline Code Example Here

int arr[]={12,17,13,11};
// printf("\n arr = %d , &arr= %d",arr,&arr);

printf("\n arr+1 = %d , &arr + 1= %d",arr+1,&arr+1);

[sepp2k]

No, I am not wrong in case of &arr+1.

Nobody said you were wrong. Gonbe said that what ss125 said ("&arr +1 means arr[]=> 2 bytes for arr and 2 bytes for array") sounded wrong, which it did - though I also have no idea what exactly was meant by that.

[sepp2k]

By the way, a couple of things I forgot to mention earlier:

The amount of bytes an integer takes up depends on the supported word size of the used CPU and there is no "default" specified in the specification.

It's true that sizeof(int) is implementation defined, but it's not necessarily equal to the supported word size. Specifically most (all?) compilers have sizeof(int) equal 4 even on 64-bit platforms.

8 and 16 bit integers

int can never have 8 bits. The C standard defines the minimal range of int and unsigned int, such that at least 16 bits are required to represent them.

[Gonbe]

try adding more elements in array and try to run it

I don't see anything in your post that you could be not "not wrong" about. All I see is output of the given code on your system followed by a question. So I'm not sure what you mean, unless you and ss125 are the same person, in that case I understand what you mean but you're then answering your own question.

[dev90]

@ Gonbe
ok...sorry..i get it another way...
And we are not same person....you can see it by 'comparing the joining time and post ratio'
and how can i misunderstand your first post as dev90 and then support you as s2pp2k???

anyways thanks for reply...:)

[Gonbe]

int can never have 8 bits. The C standard defines the minimal range of int and unsigned int, such that at least 16 bits are required to represent them.

Hmm I was pretty sure it was 8 bits when I used it, although it's quite some time ago.. If the standard says it can't be so (too lazy to check) I'm probably mixing things up.

[sepp2k]

and how can i misunderstand your first post as dev90 and then support you as s2pp2k???

ss125 (who said the thing that sounded wrong) and I (sepp2k) are two different people. And I don't think Gonbe was seriously suggesting you're the same person - he was being rhetoric.