This is deadly confusing is such array

int tab[10][10];

a lite/solid block of 100 ints (equivalent of tab[a+b*10] where a is index of right [] and b index of left [] I mean [a]) or this is really (as someone say

but it is really hard to belive for me, an array of 10 pointers to 10-int chunks)?

(so really its size is 100 ints + 10 pointers and this pointers can lay far from int contents?)

could comeone finaly explain it to me (but please tell me a sure/solid answer youre sure of, TNX)

The declaration "T foo[n][m];" in C or C++ creates an array that is equivalent to "T foo[n * m];".

It could be inferred from your question that you may believe that arrays are actually pointers. They are not. This can be confusing as arrays frequently decay into pointers, and function parameters that appear to be arrays are actually syntactic sugar for pointer declarations.

What you seem to think it is is called a ragged array (ragged because the rows can be different lengths) and, in C and C++, you'd have to create this manually

int *tab[10];
for(int i = 0; i < 10; ++i)
{
    tab[i] = new int[10];
}

There is no built-in support for ragged arrays in the way you are (I think) describing.

This is deadly confusing is such array

int tab[10][10];

a lite/solid block of 100 ints (equivalent of tab[a+b*10] where a is index of right [] and b index of left [] I mean [a]) or this is really (as someone say
but it is really hard to belive for me, an array of 10 pointers to 10-int chunks)?
(so really its size is 100 ints + 10 pointers and this pointers can lay far from int contents?)

could comeone finaly explain it to me (but please tell me a sure/solid answer youre sure of, TNX)

Moving to For Beginners, and including a bit of a longer description.

Multidimensional arrays in C and in C++ can be a bit tricky if you are coming from another language.

They work differently from how they work in Java, C#, and several others.

The line you have above, int tab[10][10]; creates a block of 100 int values. The name of the block is "tab".

It does not create an array of pointers to other arrays, which is how several other languages work.

Effectively the object "tab" points to the first value, very similar to the way a pointer works, but it is not really a pointer. It is the name of the array. The language allows the name to work almost identically to a pointer, and it can automatically get interpreted as a pointer, but it is really the name of the array.

You can access the first item in the array as tab[0][0], or as tab[0], or as *tab. The compiler treats all of these the same.

Accessing other values gets more interesting.

Logically, when you are using the array, it looks like a square shape, with 10 rows of 10 columns.

0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
30, ... etc.

In memory, it looks like a flat line of integers, 100 spaces long.

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, ... etc.

The compiler keeps track of the "tab" variable for you as a square block as long as you use array notation. But when you start using pointer notation, it automatically switches to the second, linear format.


You can access elements of the array in several ways.

First, by using its name in array form. tab[0][0] is 0, tab[0][1] is 1, tab [0][2], is 2. These all follow the square block notation. Continuing down row index 0 gives us tab[0][8] is 8. tab[0][9] is 9. ... And then we have the trickery that comes at the end of a row.

The compiler knows (because we defined a [10][10] array) that each row is 10 lines long. They are treated as offset values, so 10 values are 0 to 9. We can access the next element as tab[1][0] for 10. That will cross to the next row. But that is not the only way to cross rows.

If you refer to the memory as pointers instead of arrays, it gives you lines like this: int tab[10][10]; int* ptr = tab; ++ptr; then the pointer ptr points at the second element. Using ++ptr will advance to the third element. Another ++ptr will continue for the next value, ++ptr advancing again, all the way through the 100 values in your array. Just be careful, since you are only guaranteed to have 100 blocks of memory. You can advance one space past the end, but trying to actually use that space is undefined. It might work fine, it might crash your program, it might format your hard drive. Be careful about the end of arrays.

Internally, the language does a bit of fancy work for you. When you use a multidimensional array notation, the compiler can treat several things as equivalent. When you define an array with sizes (we'll call them ROWS and COLUMNS), such the definition "int tab[ROWS][COLUMNS];", the compiler can treat an array notation tab[x][y] as though you used the pointer notation "*(tab+(COLUMNS*x)+y)". You don't need to write out the multiplication and addition yourself, just writing tab[x][y] allows the compiler to do that work for you.

The language doesn't care if the programmer uses array notation or pointer notation, it can easily switch between the two. The compiler is just trying to figure out the right spot in memory, and for C, it doesn't matter what route you use as long as you reach the proper destination.

When you use array notation, the language knows that a multidimensional array has a specific size. When you use tab[x][y] it knows that you are trying to reach row x column y of your block of memory, and internally will find the offset with multiplication and addition, using the"*(tab+(COLUMNS*x)+y)" formula internally to interpret the array.

When using array notation, if you use fewer specifiers it will still do the same work. It will assume an unspecified index is zero. tab[1] is the same as tab[1][0] and refers to value 10, tab[2] is the same as tab[2][0] and refers to value 20, tab[3] is the same as tab[3][0] and refers to value 30, and so on. The compiler knows the size and will still do the math to find the right offset it memory.

This also means that tab[1][0], tab[0][10], and tab[2][-10] all refer to the same location in memory. You could also use *(tab+10) or *(tab+(10*1)+0) or many other ways to reach the same slot of memory. All that matters is that when the computer adds and multiplies and does all the math, the number for the memory slot is correct.

An array in C is a contiguous block of memory, the size of all the array dimensions multiplied together. When you use array notation the compiler does the math for you to find the offset into that block of memory. When you use pointer notation you need to do the math to find the offset.


You can use this for any size of multidimensional array.

If we had three dimensions, and name the dimensions RANK, ROWS, and COLUMNS, then defined a variable like "int foo[RANK][ROWS][COLUMNS];" we will make single block of integers that is RANK * ROWS * COLUMNS long. The formula applies just as well to additional dimensions. If you used foo[a][c] it is identical to using "*(foo+(a*(ROWS*COLUMNS))+(b*COLUMNS)+c)". It will do all the math internally to find the correct offset inside the block of memory.



This is very different behavior from languages like Java and C#, where multidimensional arrays work differently, which seems to be the source of your confusion. The closest thing to the Java and C# behavior is what Aardvajk wrote above. In that case you need to specify an array of arrays rather than array of int values, and then create new internal arrays. These will not be located consecutively in memory, but may be scattered everywhere. You also cannot access them with a continuous pointer notation, you will need to dereference the first array, then dereference into the second array.

You can access the first item in the array as tab[0][0], or as tab[0], or as *tab. The compiler treats all of these the same.

I don't consider those are all the same. tab[0][0] is an int, and tab[0] and *tab are arrays. The things they refer to all have the same memory address, but the compiler does not treat them all the same. Well, the last two are the same because *x and x[0] are generally the same (I think operator overloading is about the only thing that can make them work differently).

int tab[10][10];

int* p1 = tab[0];
int* p2 = (int*)tab;
int* p3 = &tab[0][0];
int (*p4)[10] = tab;

assert(p1 == p2 && p1 == p3 && p1 == *p4);

You can access the first item in the array as tab[0][0], or as tab[0], or as *tab. The compiler treats all of these the same.

I don't consider those are all the same. tab[0][0] is an int, and tab[0] and *tab are arrays. The things they refer to all have the same memory address, but the compiler does not treat them all the same. Well, the last two are the same because *x and x[0] are generally the same (I think operator overloading is about the only thing that can make them work differently).

int tab[10][10];

int* p1 = tab[0];
int* p2 = (int*)tab;
int* p3 = &tab[0][0];
int (*p4)[10] = tab;

assert(p1 == p2 && p1 == p3 && p1 == *p4);

Allright thanx for the answers all (Im not quite that newbie in c but still there are some subtle things that can confuse me)

Got yet two questons related to thing said above

1)

if i got

int tab[10][10];

what type has tab[1] ? is this an 10-int array of

{ tab[1][0], tab[1][1], ... tab[1][9] } ?

2) what is the way or recast one dimensional array into two dimensional, say i got

int tab1[100];

and want to 'recast' it into

int tab2[10][10];

I would preferably got to pointers tab1 for flat adressing and tab2 for [][] adressing of the same memory chunk)

(could then acces like tab[y][x]; could be slower or faster than hand writting of tab[y*10+x] ?)

Just think about the [] as a way for the compiler to calculate the offset from the first element of the array to the one you want.

1)

int tab[10][10];

what type has tab[1] ? is this an 10-int array of

This make no sense, it won't even compile. tab[1][0] is just a way of saying, hey, i want the int at location &tab[0][0] + (((1 * 10) + 0) * sizeof(int))

2) no need for indexing at all...

memcpy(&tab1[0], &tab2[0][0], 100 * sizeof(int));

To answer the question, i doubt it will be faster, since the compiler does the exact same thing i believe.

For your final comment about speed..

a. Let the compiler do as much as possible, it usually knows best.

b. You typically shouldn't care about performance for small things like these. Both are way faster than "enough" and trying to optimize will typically just give you headaches for other reasons.

c. There is rarely a universal answer to which is faster in these types of questions, it'll depend on lots of things and will therefore vary on a case by case basis.

1)

if i got

int tab[10][10];

what type has tab[1] ? is this an 10-int array of

{ tab[1][0], tab[1][1], ... tab[1][9] } ?

I believe Vortez meant specifically the notation you used at the bottom ( { tab[1][0], ... etc ) as 'not making sense'. I would say that tab[1] does have a type, which is an array of 10 ints. That is, if you did size(tab[1]) that would return the same result as 10*sizeof(int). This doesn't really help anything though because you can't do much with this information. You can't assign arrays to each other.

2) what is the way or recast one dimensional array into two dimensional, say i got

int tab1[100];

and want to 'recast' it into

int tab2[10][10];

I would preferably got to pointers tab1 for flat adressing and tab2 for [][] adressing of the same memory chunk)

(could then acces like tab[y][x]; could be slower or faster than hand writting of tab[y*10+x] ?)

You can't cast arrays of one type to another type like that in C.

Besides, you generally don't want to waste your time optimizing at that level. What you should be spending time on is understanding things at the algorithm level. Doesn't matter how quick it is to access tab[y][x] vs tab[y*10+x] if the algorithm you're using it in stinks. Even if you picked the best algorithms the best optimization is probably to use the appropriate compiler intrinsic. The best way to tell what to focus on and when is to understand how to profile your code. What works best in one situation won't work best in another situation.