What could be the advantages and disadvantages of decay of Nd arrays to N-level pointers?

Question

I have been thinking of a couple of possible extensions to the C language which I'd like to know the opinion of others about.¹ This one is about multi-dimensional arrays.

Imagine the following situation in C:

void matrix_mul(double **res, double **a, double **b, size_t n, size_t m, size_t r);

You cannot pass a double mat[4][4] (for example) to this function. If you define the function as:

void matrix_mul_N_M_R(double res[N][R], double a[N][M], double b[M][R]);

You'd just be wasting a perfectly written fine algorithm on a certain size of matrices.

What came to me (in shower obviously), was decay of multi-dimensional arrays to multi-level pointers. This is an extension to decay of 1d arrays to pointers.

Semantically, this would allow the first type of function to work on any two-dimensional array. Technically, this is how it would be implemented. The following code:

double a[3][5];
double b[5][4];
double c[3][4];
...
matrix_mul(c, a, b, 3, 5, 4);

would be equivalent to:

double a[3][5];
double b[5][4];
double c[3][4];
...
double **__a_decay = {a[0], a[1], a[2]};               /* generated by compiler */
double **__b_decay = {b[0], b[1], b[2], b[3], b[4]};   /* generated by compiler */
double **__c_decay = {c[0], c[1], c[2]};               /* generated by compiler */
matrix_mul(__c_decay, __a_decay, __b_decay, 3, 5, 4);  /* first three arguments decayed */

Is the application for such an extension very limited? Are there pitfalls? Could this possibly lead to insecure code where not using this feature wouldn't? Where else could such a feature come in handy?

¹ _{Note that I'm not going to make another language myself, but would like to be sure of the feature's benefits and pitfalls before trying to suggest them to the C Standard Committee.}

Answer 1

How would your proposed extension handle the situation where a multi-dimensional array isn't allocated statically? Having the extension be limited to cases where the allocation is static would make its behavior inconsistent with other array handling, but if the extension isn't limited to static array allocations then passing a double[5000][5000] to function which is expecting a double** would require the compiler to generate and fully populate a (double*)[5000], even if the function wouldn't use most of (or even any of) its elements each time the function was called.

A more useful extension might be to add types like double[][] and double[][][] as types in the language, and have each such type with N dimensions be stored as a double* along with N-1 values of type type size_t. It would be necessary to have separate methods for jagged and linear arrays, but it would not be necessary to have different methods for each size of linear array.

Answer 2

Perhaps you have heard the famous quote of Antoine de Saint-Exupery before:

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

So before thinking about language extensions one should think about solving a problem with the existing language features in a convenient way (and I guess that's what the C standard commitee will answer you if you really make such a proposal).

In C, the natural solution to this kind of problem is to define a

struct Matrix
{
    int sizeX;
    int sizeY;
    double *values; /* vector with sizeX * sizeY elements */
};

(or something similar), and create operations working on that kind of data type, including operations for memory allocation and freeing, operations to fill that kind of structure with values from a 2D-array etc.

Answer 3

The biggest problem with this seems to me to be that it's taking the C concept of arrays decaying to pointers and building on it.

Arrays decaying to pointers is already problematic in terms of clarity. If you see a function that takes a parameter of type int*, does this mean it expects an array of integers, or a single integer as a "fake passed-by-reference" argument? There's no way to know without examining the code of the function--or the documentation, assuming it exists and is up-to-date and accurate.

If you then expand on this to multiple levels of array-decay, the complexity and uncertainty grows exponentially with each dimension...

Answer 4

Note with C99 and optionally since C11, code can use a variable length array to achieve OP's goal.

Then the arrays convert as desired.

// void matrix_mul_N_M_R(double res[N][R], double a[N][M], double b[M][R]);
void matrix_mul_N_M_R(size_t n, size_t m, size_t r, 
    double res[n][r], double a[n][m], double b[m][r]);

One pitfall is that since C11, it is an optional feature. Research __STDC_NO_VLA__¹,

---

¹ __STDC_NO_VLA__ The integer constant 1, intended to indicate that the implementation does not support variable length arrays or variably modified types.