> I mean the inability to pass an array to a function as an array, even if it is declared to be an array.
This is possible for fixed-length arrays using 'myType (*myVar)[size]' as the argument type.
This is possible for fixed-length arrays using 'myType (*myVar)[size]' as the argument type.
The annoying thing about this is that the array is just sitting there on the stack of the calling function. The size is completely known at compile time. But it gets thrown away as soon as you call a function.
If the syntax is the problem, yeah, if you want first class data structures you might not like C.
The title of the article is “C’s biggest mistake.” If you’re going to rebut the article, do so. Otherwise your reply just comes off as “this is the way it is, deal with it!” which is a pretty shallow dismissal.
That's what an array is. Fixed size. If we want to talk about a slice of some runtime determined amount of a thing then we need fat pointers, and C doesn't provide any fat pointer types so it's not a surprise to find it can't do slices.
There is no reason this shouldn’t be possible. It should not require fat pointers at all because the size information is known at compile time.
This is exactly the solution proposed in TFA..
> using the int array1[2]; like this: arraytest(array1); causes array1 to automatically decay into an int .
> HOWEVER, if you take the address of array1 instead and call arraytest(&array1), you get completely different behavior!
> Now, it does NOT decay into an int