Viewing arrays in AppCode debugger


How do I make the latest AppCode debugger show arrays like it used to in version 3.1?

Here is a simple app to show the problem:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, const char * argv[]) {
int i, j;
double *darr;
double **ddarr;

darr = malloc(100 * sizeof(double));
for (i = 0; i < 100; i++) darr[i] = i;

ddarr = malloc(10 * sizeof(double*));
for (i = 0; i < 10; i++) ddarr[i] = malloc(10 * sizeof(double));

for (i = 0; i < 10; i++) {
for (j = 0; j < 10; j++) {
ddarr[i][j] = i*10+j;

// Examine darr and ddarr in the debugger

for (i = 0; i < 10; i++) free(ddarr[i]);


return 0;

Here is a snapshot of the Variable view in the latest AppCode that doesn't show arrays:

Here is a snapshot of the Variable view in the old AppCode 3.1 debugger:

and viewing 2D arrays:

The old AppCode 3.1 variables view is really nice! The latest AppCode variables view is almost useless for viewing arrays. How do I make the latest AppCode work like the older version?



I see a similar behaviour with NSManagedObjects of Core Data. With AppCode 2016.1.3 the properties of the entities are visible:


In AppCode 2016.2 ist looks like this:


I have created an issue for this:


I got a response the same day from JetBrains support. This is why arrays show differently:

"The problem with this snippet is that there aren't any arrays, only pointers, and the debugger treats them as such. The debugger has no way of knowing whether the data at the pointer is an array or a single element. The previous behavior worked in certain cases, but much more often it would cause problems, so it was removed.

We are planning to add an ability to show an arbitrary pointer as an array:

In the meantime you can do something like (double(*)[10])darr whenever you need to evaluate the contents. You can use such expression in Watches too."

That sounds reasonable to me. I tried casting the 2D array value to (double(**)[10] and that works too but limits the second dimension to 10. If the array is ragged or the dimensions are different, it looks like you need to cast it to (double(**)[n]) where n is the largest dimension.



Thanks for mentioning this. I wasn't aware of that.

The other bug I reported was fixed in the new EAP released today. That was quick :-)