Don't even get me started on packing when you have arrays of structs...
A convenient untruth: Array notation in C is a lie
51–60 of 176 posts
Re: A convenient untruth: Array notation in C is a lie
#52C now has static array indices.
For example
void func(int arr[static 8]) {}
imposes a limit on the size of the array that can be passed as an argument (you cannot pass an array of 7 or fewer elements.)
I'd suggest that to the author, but given the article, I fear it may give him a heart attack.
Re: A convenient untruth: Array notation in C is a lie
#53C now has static array indices. For example void func(int arr[static 8]) {} imposes a limit on the size of the array that can be passed as an argument (you cannot pass an array of 7 or fewer elements.) I'd suggest that to the author, but given the article, I fear it may give him a heart attack.
What version of C is this in? And do modern implementations (clang, GCC) adhere to it (without extensions)?
Re: A convenient untruth: Array notation in C is a lie
#54The equivalent in C# always made more sense to me (not comparing memory or allocation model between the languages, but simply syntax in relation to a person reading it): int[] arr = new int[5]; // C# int arr[5]; // C The fact that the brackets go on the datatype always made more sense to me, after all, I want to refer to memory of a certain cell size (as indicated by int). I realize that there is a lot of stuff going…
> I will now duck and get far away from the internet, in fear of all the hateful comments explaining to me how I am wrong, and apparently just don't understand the superior beauty of complicated C syntax. I am going to be that person :-) One phrase – "declarations mirror use". In a declaration, you use the same set of operators around the declared object that you would use in a normal expression. All of these operato…
I think if all type-information were kept together, it might read simpler:
char*[X] arr;
It would be interesting if the use did "mirror" declaration:
arr[5]*
Just some random thoughts...
Re: A convenient untruth: Array notation in C is a lie
#55Earlier quoted context omitted.
You're describing a general problem in general terms... Does a program that has no side effects even exist?? ooOOOoh, spooky.... BTW, yes I know what you're getting at... optimisers are allowed to perform any transformation as long as they're semantically equivalent. This applies to all languages.
> This applies to all languages. Sure, but it's common for C programmers to think C is a low-level language with concepts that map straightforwardly to the target machine. You can't simultaneously think that C is a low-level language "close to the machine" and that your program can be freely rewritten into an eldritch horror. That's the only reason it would be a good "lie". Contrast that with something like Perl, whe…
C programmers are not thinking that C is low level language. ;-)
Assembler language is low-level language, because it is not portable between architectures. C is high-level language, because it's portable. It's means that one C language statement can be translated into many statements of assembler language, hence C has higher level of abstraction than assembler language.
Re: A convenient untruth: Array notation in C is a lie
#56The equivalent in C# always made more sense to me (not comparing memory or allocation model between the languages, but simply syntax in relation to a person reading it): int[] arr = new int[5]; // C# int arr[5]; // C The fact that the brackets go on the datatype always made more sense to me, after all, I want to refer to memory of a certain cell size (as indicated by int). I realize that there is a lot of stuff going…
I don't agree with: int[5] arr; being a more readable syntax. The problem is that if you later have: int[7] arr2; It would make sense that arr and arr2 are different types (as the thing on the left is different) while they are the same type and you should be able (hopefully!) to use them as arguments to the same function. On the other hand I agree that: int* arr; makes more sense than more commonly used: int *arr; al…
although it's messed up anyway as
But that's because they wanted it to be like that.
To me, this code is very unclear:
int a, *b, c, d;
I'd be much happier if they were all strictly different and that
int* a, b, c, d;
Re: A convenient untruth: Array notation in C is a lie
#57C now has static array indices. For example void func(int arr[static 8]) {} imposes a limit on the size of the array that can be passed as an argument (you cannot pass an array of 7 or fewer elements.) I'd suggest that to the author, but given the article, I fear it may give him a heart attack.
What version of C is this in? And do modern implementations (clang, GCC) adhere to it (without extensions)?
It is C99 so it has been part of the language for a very long time
Re: A convenient untruth: Array notation in C is a lie
#58But this is exactly what the index operator is doing. When you write (for example) arr[0] The compiler is re-writing your code as: *(arr + 0) Since addition is commutative, you can also write arr[0] as 0[arr].
Yes, it's in the article.
Re: A convenient untruth: Array notation in C is a lie
#59Regarding #3, it's worth noting that even though the elements of the two-dimensional array form a contiguous block of integers, you cannot treat them as such [1].
Re: A convenient untruth: Array notation in C is a lie
#60Earlier quoted context omitted.
What version of C is this in? And do modern implementations (clang, GCC) adhere to it (without extensions)?
It is C99 so it has been part of the language for a very long time
Just to add, from the N1256 draft of C99, 6.7.5.3:
A declaration of a parameter as ‘‘array of type’’ shall be adjusted to ‘‘qualified pointer to type’’, where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation. If the keyword static also appears within the [ and ] of the array type derivation, then for each call to the function, the value of the corresponding actual argument shall provide access to the first element of an array with at least as many elements as specified by the size expression.