I am declaring a two dimensional array as such:
char arr[10][10];
arr[0][0] = 'X';
Now I print in debugger;
(lldb) po arr[0][0]
'X'
Awesome!! No problem.
Now I am declaring a two dimensional array as such:
int col = 10;
int row = 10;
char arr[row][col];
arr[0][0] = 'X';
Now I print in debugger;
(lldb) po arr[0][0]
error: subscript of pointer to incomplete type 'char []'
error: 1 errors parsing expression
Why??
The debugger doesn't know exactly how big the array is, so you need to apply a cast:
(gdb) p ((char (*)[10])arr)[0][0]
$2 = 88 'X'
arr[10][3] would it need to be p ((char (*)[3])arr)[0][0]?
((char (*)[10]arr)[0][0]?arr is an int [3]. The cast you give would say that each element is instead a int [10], so the sizes and offsets would be wrong.So dbush is right. But here's why in a little more depth.
char arr[10][10];
isn't the same thing as
char arr[row][col];
Even though they look and act similar.
In the C89 standard, the second would be illegal as the compiler has no idea how much space to allocate for the variable (even though that's defined in the previous two lines).
Enter the C99 standard and they introduced something called variable length arrays. The space allocation for the array is determined at runtime rather then at compile-time. Now you can pass in a couple of variables to a function and declare an array with a size based on those variables. Yay!
But it means the compiler officially doesn't know details about the array. Like how big it is. And LLDB uses the Clang/LLVM compiler to make sense of the code.
It's an example of the language becoming slightly higher level and abstracting the work it does under the hood. And occasionally that bites you in the ass.
make the col and row const
const int col = 10;
const int row = 10;
const will not make a difference. In C language const on col and row will not prevent the array from becoming VLA and thus will have no effect of the original issue.
double array as such:means?doublemakes you think of floats.