问题
I went through this article. I understand the rules explained but I am wondering what exactly blocks the compiler from accepting the following syntax when defining a constant multi-dimensional array and directly initializing it with known values of given type:
const int multi_arr1[][] = {{1,2,3}, {1,2,3}}; // why not?
const int multi_arr2[][3] = {{1,2,3}, {1,2,3}}; // OK
error: declaration of 'multi_arr1' as multidimensional array must have bounds
for all dimensions except the first
What prevents the compiler from looking to the right and realizing that we are dealing with 3 elements for each "subarray" or possibly returning an error only for cases when the programmer passes e.g. a different number of elements for each subarray like {1,2,3}, {1,2,3,4}?
For example when dealing with a 1D char array the compiler can look at the string on the right hand side of = and this is valid:
const char str[] = "Str";
I would like to understand what's happening so that the compiler is not able to deduce the array dimensions and calculate the size for allocation since now it seems to me like the compiler has all the information needed to do so. What am I missing here?
回答1:
Requiring the compiler to infer inner dimensions from the initializers would require the compiler to work retroactively in a way the standard avoids.
The standard allows objects being initialized to refer to themselves. For example:
struct foo { struct foo *next; int value; } head = { &head, 0 };
This defines a node of a linked list that points to itself initially. (Presumably, more nodes would be inserted later.) This is valid because C 2011 [N1570] 6.2.1 7 says the identifier head “has scope that begins just after the completion of its declarator.” A declarator is the part of the grammar of a declaration that includes the identifier name along with the array, function, and/or pointer parts of the declaration (for example, f(int, float) and *a[3] are declarators, in a declarations such as float f(int, float) or int *a[3]).
Because of 6.2.1 7, a programmer could write this definition:
void *p[][1] = { { p[1] }, { p[0] } };
Consider the initializer p[1]. This is an array, so it is automatically converted to a pointer to its first element, p[1][0]. The compiler knows that address because it knows p[i] is an array of 1 void * (for any value of i). If the compiler did not know how big p[i] was, it could not calculate this address. So, if the C standard allowed us to write:
void *p[][] = { { p[1] }, { p[0] } };
then the compiler would have to continue scanning past p[1] so it can count the number of initializers given for the second dimension (just one in this case, but we have to scan at least to the } to see that, and it could be many more), then go back and calculate the value of p[1].
The standard avoids forcing compilers to do this sort of multiple-pass work. Requiring compilers to infer the inner dimensions would violate this goal, so the standard does not do it.
(In fact, I think the standard might not require the compiler to do any more than a finite amount of look-ahead, possibly just a few characters during tokenization and a single token while parsing the grammar, but I am not sure. Some things have values not known until link time, such as void (*p)(void) = &SomeFunction;, but those are filled in by the linker.)
回答2:
There is nothing impossible in implementing compilers that would deduce the innermost dimensions of multidimensional arrays in presence of an initializer, however, it is a feature that is NOT supported by C or C++ standards, and, evidently, there has been no great demand for that feature to bother.
In other words, what you're after is not supported by the standard language. It could be supported if enough people needed it. They don't.
回答3:
To briefly expand on the comment:
What "blocks" the compiler is adherence to the standard (for C or C++, they're different standards, pick one).
What "blocks" the standard from allowing this is no-one wrote a standards proposal for implementing it which was subsequently accepted.
So, all you're asking is why no-one was motivated to do something you feel would be useful, and I can only see that as opinion-based.
There may also be practical difficulties implementing this, or keeping consistent semantics; that's not precisely the question you asked, but it might at least be objectively answerable. I suspect someone could work through those difficulties if sufficiently motivated. Presumably no-one was.
For example, (reference), the syntax a[] really means array of unknown bound. Because the bound can be inferred in the special case when it's declared using aggregate initialization, you're treating it as something like a[auto]. Maybe that would be a better proposal, since it doesn't have the historical baggage. Feel free to write it up yourself if you think the benefits justify the effort.
回答4:
The rule is that compiler determines only first dimension of the array by the given initializer list. It expects second dimension to be specified explicitly. Period.
回答5:
With an array, the compiler has to know how big each element is so that it can do index calculation. For example
int a[3];
is an integer array. The compiler knows how big an int is (usually 4 bytes) so it can calculate the address of a[x] where x is an index between 0 and 2.
A two dimensional array can be thought of as a one dimensional array of arrays. e.g.
int b[2][3];
is a two dimensional array of int but it is also a one dimensional array of arrays of int. i.e. b[x] refers to an array of three ints.
Even with arrays of arrays, the rule that the compiler must know the size of each element still applies which means that in an array of arrays, the second array must be of fixed size. If it were not, the compiler couldn't calculate the address when indexing i.e. b[x] would be impossible to calculate. Hence the reason why multi_arr2 in you're example is OK, but multi_arr1 is not.
What prevents compiler from looking to the right and claim that we are dealing 3 elements for each "subarray" or possibly return error only for cases when programmer passes e.g. different number of elements for each subarray like {1,2,3}, {1,2,3,4}
Probably a limitation of the parser. By the time it gets to the initialiser, the parser has already gone past the declaration. The earliest C compilers were pretty limited and the behaviour above was set as expected long before modern compilers arrived.
来源：https://stackoverflow.com/questions/48864897/why-is-char-not-possible-if-explicitly-given-a-multidimensi