why two dimensional is not equal to one dimemsional - c

a[6]={1,2,3,4,5,6};
memory layout for a
1 2 3 4 5 6
addr 2002 2006 2010 2014 2016 2020
b[2][3]={1,2,3,4,5,6};
memory layout for b
1 2 3 4 5 6
addr 2002 2006 2010 2014 2016 2020
both a and b are same
why a[1] address is 2006 and b[1] address is 2010 both are different. arrays are stored contiguously why they are different. So I have doubt what is braket[][] in array we know that memory consist of address not columns and rows.

The answer lies in the type of what results. Almost whenever an array is mentioned in C, it decays into a pointer to its first element. Now for your two cases:
The type of a is int ()[6] which decays into a pointer to int int* before doing the pointer arithmetic implied by a[1]. The expression a[1] is precisely equivalent to *(a + 1). This pointer addition will advance the pointer by one int, because that is what the pointer points at.
The type of b is int ()[2][3] which decays into a pointer to an array int (*)[3]. The size of the array that the pointer points at is three integers. As such, *(b + 1) advances the pointer by three integers.

For the second array, the memory layout is actually
+---------+---------+---------+---------+---------+---------+
| b[0][0] | b[0][1] | b[0][2] | b[1][0] | b[1][1] | b[1][2] |
+---------+---------+---------+---------+---------+---------+

Let's set this clear once and for all:
First, let's imagine that both a and b are mapped into the exact same memory region. That is, both a[0] and b[0][0] are stored in contiguous memory positions starting at the same address.
With this in mind, note that a[1] and b[1] are not the same memory location. Why? Because a is an array of integers, and b is an array of arrays of integers. Each position in b is an array of 3 integers; each position in a is an integer.
Thus, a[1] is not the same memory address as b[1], because b[1] is 3*sizeof(b[0][0]) bytes away from b[0][0], and a[1] is sizeof(a[0]) bytes away from a[0]. Thus, the offsets are different, even though the arrays layout is the same in memory. Your confusion around a[1] and b[1] relates to the fact that the index is the same, but means different things.
a[1] is equivalent to *(a+1), and b[1] is equivalent to *(b+1). The thing is, a+1 and b+1 scale 1 by different amounts (again, by sizeof(a[0]) and 3*sizeof(b[0][0]), respectively). That's why the addresses are different.
In particular, &b[1] is be the same as &a[3].

Related

Related to pointers in C language [duplicate]

When we subtract a pointer from another pointer the difference is not equal to how many bytes they are apart but equal to how many integers (if pointing to integers) they are apart. Why so?
The idea is that you're pointing to blocks of memory
+----+----+----+----+----+----+
| 06 | 07 | 08 | 09 | 10 | 11 | mem
+----+----+----+----+----+----+
| 18 | 24 | 17 | 53 | -7 | 14 | data
+----+----+----+----+----+----+
If you have int* p = &(array[5]) then *p will be 14. Going p=p-3 would make *p be 17.
So if you have int* p = &(array[5]) and int *q = &(array[3]), then p-q should be 2, because the pointers are point to memory that are 2 blocks apart.
When dealing with raw memory (arrays, lists, maps, etc) draw lots of boxes! It really helps!
Because everything in pointer-land is about offsets. When you say:
int array[10];
array[7] = 42;
What you're actually saying in the second line is:
*( &array[0] + 7 ) = 42;
Literally translated as:
* = "what's at"
(
& = "the address of"
array[0] = "the first slot in array"
plus 7
)
set that thing to 42
And if we can add 7 to make the offset point to the right place, we need to be able to have the opposite in place, otherwise we don't have symmetry in our math. If:
&array[0] + 7 == &array[7]
Then, for sanity and symmetry:
&array[7] - &array[0] == 7
So that the answer is the same even on platforms where integers are different lengths.
Say you have an array of 10 integers:
int intArray[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
Then you take a pointer to intArray:
int *p = intArray;
Then you increment p:
p++;
What you would expect, because p starts at intArray[0], is for the incremented value of p to be intArray[1]. That's why pointer arithmetic works like that. See the code here.
"When you subtract two pointers, as long as they point into the same array, the result is the number of elements separating them"
Check for more here.
This way pointer subtraction behaves is consistent with the behaviour of pointer addition. It means that p1 + (p2 - p1) == p2 (where p1 and p2 are pointers into the same array).
Pointer addition (adding an integer to a pointer) behaves in a similar way: p1 + 1 gives you the address of the next item in the array, rather than the next byte in the array - which would be a fairly useless and unsafe thing to do.
The language could have been designed so that pointers are added and subtracted the same way as integers, but it would have meant writing pointer arithmetic differently, and having to take into account the size of the type pointed to:
p2 = p1 + n * sizeof(*p1) instead of p2 = p1 + n
n = (p2 - p1) / sizeof(*p1) instead of n = p2 - p1
So the result would be code that is longer, and harder to read, and easier to make mistakes in.
When applying arithmetic operations on pointers of a specific type, you always want the resulting pointer to point to a "valid" (meaning the right step size) memory-address relative to the original starting-point. That is a very comfortable way of accessing data in memory independently from the underlying architecture.
If you want to use a different "step-size" you can always cast the pointer to the desired type:
int a = 5;
int* pointer_int = &a;
double* pointer_double = (double*)pointer_int; /* totally useless in that case, but it works */
#fahad Pointer arithmetic goes by the size of the datatype it points.So when ur pointer is of type int you should expect pointer arithmetic in the size of int(4 bytes).Likewise for a char pointer all operations on the pointer will be in terms of 1 byte.

How to understand this pointer to a data structure in C?

I have this code, I'm trying to figure out what the second line of code does.
static int table [][4]= {{1,2,3,4},{2,3,4,5},{3,4,5,6}};
int valore = *(*(table+2)+1);
printf("%d",valore);
I have a basic knowledge of pointers in C, can you explain me what does the second line of code do please?
Your table is simply a 2D array of integers. In C a 2D array is really an "array or arrays". Your table has the dimensions of static in table[3][4]; (3 rows x 4 cols), it is an array of 3 integer arrays with 4 elements each. Since it is an array, all values will be sequential in memory. You can think of the memory layout as follows.
+---+---+---+---+
table[0] | 1 | 2 | 3 | 4 |
+---+---+---+---+
table[1] | 2 | 3 | 4 | 5 |
+---+---+---+---+
table[2] | 3 | 4 | 5 | 6 |
+---+---+---+---+
An array is converted to a pointer on access (accept in 4 limited circumstances, not relevant here, see C11 Standard - 6.3.2.1 Other Operands - Lvalues, arrays, and function designators(p3) for details)
You are introduced to "pointer notation" in the question. You can access any element of an array using "array indexes" or "pointer notation". In pointer notation *(a + b) is equivalent to a[b] in array index notation. You have:
*(*(table+2)+1)
If you take it piece by piece *(table + 2) is simply table[2]. Next *(table[2] + 1) is simply table[2][1]. So you are acccessing the 2nd value in the 3rd row with either (which is simply 4).
Look things over and let me know if you have further questions.
table is an array of 3 arrays of 4 int.
When an array is used in an expression, it is converted to a pointer to its first element, except when:
It is the operand of sizeof.
It is the operand of unary &.
It is a string literal used to initialize an array.
So, in *(*(table+2)+1), table is converted to a pointer to its first element, producing &table[0]. Then we have:
*(*(&table[0]+2)+1)
Next, we have the addition &table[0] + 2. This uses pointer arithmetic. Adding an integer to a pointer (into an array) moves the pointer backward or forward by a number of elements. So &table[0] + 2 produces a pointer to table[2], which is &table[2]. Then we have:
*(*(&table[2])+1)
The inner parentheses are no longer needed, so we have:
*(*&table[2]+1)
Then * &table[2] is the thing that &table[2] points to, which means it is table[2]:
*(table[2] + 1)
Since table is an array of 3 arrays of 4 int, table[2] is an array of 4 int. Since it is an array, it is converted to a pointer to its first element, producing &table[2][0]:
*(&table[2][0] + 1)
Now we have pointer arithmetic again. &table[2][0] is a pointer to element 0 of the array table[2], so adding 1 produces a pointer to element 1, &table[2][1]:
*(&table[2][1])
Again we have parentheses that are no longer needed:
*&table[2][1]
And, finally, * &table[2][1] is the thing that &table[2][1] points to, so it is just:
table[2][1]

Subtracting addresses in a 3d array

I created a 3d array
a[2][3][2]
Now when I try to print
printf("%d",a[1] - a[0]);
I get 3 as the output.
What I understand is that a[1] gives me the address of a[1][0][0] element and a[0] the address of a[0][0][0].
Let Address of a[0][0][0] is BA then Address of a[1][0][0] is BA + 4*2*3 where 4 byte is the memory space of an integer datatype
I was expecting the result to be 6.
Similarly I tried
printf("%d",(&a + 1) - &a);
and the output received was 1.
Where am I going wrong?
Edit 1: Entire Code
#include<stdio.h>
int main(){
int a[2][3][2] = {{{1,2},{3,4},{5,6}},{{7,8},{9,10},{11,12}}};
printf("%d",a[1]-a[0]);
return 0;
}
What I understand is that a[1] gives me the address of a[1][0][0] element and a[0] the address of a[0][0][0].
This is wrong a[0] will give the address of the first 2D array. The address of the first 2D array and the address of a[0][0][0] might be co-incident, but they are not the same.
Specifically &a +1 is not equal to &a[0][0][0] +1
Let's break the expression a[1] - a[0] apart:
a[1] - refers to the second [3][2] array.
a[0] - refers to the first [3][2] array.
Now, when arrays are used in most contexts, they decay into pointers to the first element. So a[i] will decay into a pointer to a 2d array int(*)[2].
The difference is calculated in sizeof(int[2]) as dictated by pointer arithmetic. And you can see that there are 3 units of int[2] in the range [a[0], a[1]).

Multidimensional array and addressing

I have an issue with the multidimensional arrays. Maybe the solution is much easier.
int arr[2][2]; //multidimensional array
My simple question is: why the
arr[0][2] and arr[1][0]
or
arr[1][2] and arr[2][0]
are on the same address in my case?
I checked this problem in Linux and Windows environment. And the issue is the same. I have checked tutorials and other sources, but no answer.
The pointer &arr[0][2] is the one-past-the-end pointer of the array arr[0]. This is the same address as that of the first element of the next array, arr[1], which is &arr[1][0], because arrays are laid out contiguously in memory.
arr[2][0] is a bit tricker: arr[2] is not a valid access, but &arr[2] is the one-past-the-end pointer of the array arr. But since that pointer cannot be dereferenced, it doesn't make sense to talk about arr[2][0]. arr doesn't have a third element.
C stores multi-dimensional arrays in what is called row-major order. In that configuration, all the data for a single row is stored in consecutive memory:
arr[2][2] -> r0c0, r0c1, r1c0, r1c2
The alternative would be column-major order, which places the columns consecutively.
Since you have specified the length of the row (number of cols) as 2, it follows that accessing column 2 (the third column) will compute an address that "wraps around" to the next row.
The math looks like:
&(arr[row][col])
= arr # base address
+ row * ncols * sizeof(element)
+ col * sizeof(element)
= arr + sizeof(element) * (row * ncols + col)
In your case, arr[0][2] is arr + (0*2 + 2) * sizeof(int), while arr[1][0] is arr + (1*2 + 0)*sizeof(int).
You can do similar math for the other variations.
Array indexing is identical to pointer arithmetic (actually, the array name first is converted ("decays") to a pointer to the first element before the []-operator is applied):
arr[r][c] <=> *(arr + r * INNER_LENGTH + c)
Your array has two entries per dimension. In C indexes start from 0, so for each dimension valid indexes are 0 and 1 (i.e. total_entries - 1). Which makes three of your expressions suspective in the first place:
arr[0][2] // [outer dimension/index][inner dimension/index]
arr[1][2]
arr[2][0]
We have these cases:
Both indexes are valid: no problem.
Only the address is taken, the element is not accessed and
the outer index is valid and the inner (see below) index equals the length of the inner dimension: comparison and certain address arithmetic is allowed (other constraints apply!).
the outer index equals the length of the outer dimension, and the inner index is 0: The same.
Anything else: the address is invalid and any usage (take address, dereference, etc.) invokes undefined behaviour.
What exactly goes on in memory might become a bit more clear if we use different lengths for the dimensions and have a look how the data is stored:
int arr[3][2];
This is an "array of 3 arrays of 2 int elements". The leftmost dimension is called the "outer", the rightmost the "inner" dimension, because of the memory layout:
arr[0][0] // row 0, column 0
arr[0][1] // row 0, column 1
arr[1][0] // ...
arr[1][1]
arr[2][0]
arr[2][1]
Using the formula above, &arr[0][2] (arr + 0 * 2 + 2) will yield the same as &arr[1][0] (arr + 1 * 2 + 0), etc. Note, however, while the addresses are identical, the first version must not be dereferenced and the compiler may generate incorrect code, etc.
Array indexing in C is similar to adding the value of the index to the address of the first element.
In the multidimensional array that you describe, you have 2 elements on each dimension: 0 and 1. When you introduce a number larger than that, you're referencing an element outside that dimension. Technically, this is an array out of bounds error.
The addresses break down like this:
arr[0][0] - &arr[0] + 0
arr[0][1] - &arr[0] + 1
arr[1][0] - &arr[0] + 2
arr[1][0] - &arr[0] + 3
When you write arr[0][2], you're referencing address &arr[0] + 2, which is the same as arr[1][0]. It all just pointer math, so you can work it out pretty easily once you know how it works.
You can look in your two dimensional array as a long one dimensional array:
[00][01][10][11]
With the pointers arithmetic, another representation of this long one dimensional array is:
[00][01][02][03]
So looking in cell [10] is exactly the same as looking into a cell [20] in pointer arithmetic point of view.

Pointer subtraction confusion

When we subtract a pointer from another pointer the difference is not equal to how many bytes they are apart but equal to how many integers (if pointing to integers) they are apart. Why so?
The idea is that you're pointing to blocks of memory
+----+----+----+----+----+----+
| 06 | 07 | 08 | 09 | 10 | 11 | mem
+----+----+----+----+----+----+
| 18 | 24 | 17 | 53 | -7 | 14 | data
+----+----+----+----+----+----+
If you have int* p = &(array[5]) then *p will be 14. Going p=p-3 would make *p be 17.
So if you have int* p = &(array[5]) and int *q = &(array[3]), then p-q should be 2, because the pointers are point to memory that are 2 blocks apart.
When dealing with raw memory (arrays, lists, maps, etc) draw lots of boxes! It really helps!
Because everything in pointer-land is about offsets. When you say:
int array[10];
array[7] = 42;
What you're actually saying in the second line is:
*( &array[0] + 7 ) = 42;
Literally translated as:
* = "what's at"
(
& = "the address of"
array[0] = "the first slot in array"
plus 7
)
set that thing to 42
And if we can add 7 to make the offset point to the right place, we need to be able to have the opposite in place, otherwise we don't have symmetry in our math. If:
&array[0] + 7 == &array[7]
Then, for sanity and symmetry:
&array[7] - &array[0] == 7
So that the answer is the same even on platforms where integers are different lengths.
Say you have an array of 10 integers:
int intArray[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
Then you take a pointer to intArray:
int *p = intArray;
Then you increment p:
p++;
What you would expect, because p starts at intArray[0], is for the incremented value of p to be intArray[1]. That's why pointer arithmetic works like that. See the code here.
"When you subtract two pointers, as long as they point into the same array, the result is the number of elements separating them"
Check for more here.
This way pointer subtraction behaves is consistent with the behaviour of pointer addition. It means that p1 + (p2 - p1) == p2 (where p1 and p2 are pointers into the same array).
Pointer addition (adding an integer to a pointer) behaves in a similar way: p1 + 1 gives you the address of the next item in the array, rather than the next byte in the array - which would be a fairly useless and unsafe thing to do.
The language could have been designed so that pointers are added and subtracted the same way as integers, but it would have meant writing pointer arithmetic differently, and having to take into account the size of the type pointed to:
p2 = p1 + n * sizeof(*p1) instead of p2 = p1 + n
n = (p2 - p1) / sizeof(*p1) instead of n = p2 - p1
So the result would be code that is longer, and harder to read, and easier to make mistakes in.
When applying arithmetic operations on pointers of a specific type, you always want the resulting pointer to point to a "valid" (meaning the right step size) memory-address relative to the original starting-point. That is a very comfortable way of accessing data in memory independently from the underlying architecture.
If you want to use a different "step-size" you can always cast the pointer to the desired type:
int a = 5;
int* pointer_int = &a;
double* pointer_double = (double*)pointer_int; /* totally useless in that case, but it works */
#fahad Pointer arithmetic goes by the size of the datatype it points.So when ur pointer is of type int you should expect pointer arithmetic in the size of int(4 bytes).Likewise for a char pointer all operations on the pointer will be in terms of 1 byte.

Resources