4 ms·
It would help if you define what you mean by "object". This term has a definition in the C standard by which arrays are unquestionably objects. It is true that
by hvdijk 6y ago
It would help if you define what you mean by "object". This term has a definition in the C standard by which arrays are unquestionably objects. It is true that you cannot pass or return them by value, but that does not mean they are not objects, that means the ability to pass or return things by value is not a property of objects.
About the singular vs array question: this is true but just a special case of the absence of bounds checking, is it not? C's approach of allowing e.g. "int i;" to be addressed as if it were an array of length 1, allowing construction not just of &i but also &i+1 as pointer values, is valid and sometimes useful, but you have to make sure you never access *(&i+1). That's the same problem as how given "int a[2];", accessing a[2] is not valid, as far as I can see.
- jstimpfle 6y agoWhat GP means is "there are no array expressions in C's syntax". You can't copy them or assign them, and I'm not sure that they are part of any kind of "type system" in C (although some compilers have a notion of array type internally, which is obvious from their error messages).
- hvdijk 6y agoThat's just not true, there are array expressions, and arrays are part of the type system. I give him more credit than that. (The "you can't copy them" is technically untrue as well but that is just because of sloppy wording.)
- jstimpfle 6y agoYou're right, I forgot about compound literals, which were introduced in C99 and which are a rarely used feature. But I guess my statement that "C doesn't have array expressions" was true before the advent of C99. And that's also why array decay made even more sense back then. (It still makes a lot of sense today IMO).
- hvdijk 6y agoI didn't mean compound literals, I do not really see how they change things here, I meant that there are a few cases where arrays don't decay to pointers, and supporting those requires compilers to make arrays a part of the type system. Example: given "int a[3];", how else would you compute (&a+1) ?
- jstimpfle 6y agoTo me, the question is what is actually "the type system" and what is "the allocation system" or whatever else aspect of implementing a compiler. So determining the type of "&a" is not an issue, it's just one case in determining the type of a C expression (look up the object "a", is it an array? The type of the expression is a pointer to the array element type). This is not a special case, at least not more special than how to determine the type of the expression "a", or "1". No array type needed.
- hvdijk 6y agoAre you aware that given int a[3];, (&a+1) and (a+3) denote the same address? If you are, how can that possibly work if as you suggest, &a and a are indistinguishable to the compiler, that they are both seen as a pointer to int?
- jstimpfle 6y agoThat came quite honestly as a huge surprise to me. I've never seen this before. Thanks for the heads up!