Why did people think otherwise? Chapter 5 of K&R[1] is titled Pointers and Arrays and basically explains that arrays and pointers are equivalent.
[1]: https://www.amazon.com/Programming-Language-Brian-W-Kernigha...
A convenient untruth: Array notation in C is a lie
71–80 of 176 posts
Re: A convenient untruth: Array notation in C is a lie
#72In the last example, > char string[] = "Hello world"; I thought that gives out warning these days. Isn't the proper type of a string literal the following? > const char string[] = "Hello world"; Therefore, you can't really modify individual characters there.
You're confusing things a little bit. 'char s[] = "foo"' is equivalent to 'char s[] = { 'f', 'o', 'o', '\0' }' and gives you a normal mutable array (or you can make it const and then it's const; no surprises); it is okay to mutate that array. 'char * s = "foo"' gives you a pointer to a string literal that might be placed in read-only storage; in C++ it is a const char * (so modern compilers should complain about that initialisation), while in C it is a char * where it's UB if you modify it (compilers may warn about storing it in a non-const char *; many don't).
Re: A convenient untruth: Array notation in C is a lie
#73In the last example, > char string[] = "Hello world"; I thought that gives out warning these days. Isn't the proper type of a string literal the following? > const char string[] = "Hello world"; Therefore, you can't really modify individual characters there.
> Isn't the proper type of a string literal the following?
No, it's a const char pointer. Your declaration actually makes a copy of the "Hello world" string into a new char array, distinct from the string literal itself:
[~]$ cat test.c
#include
int main(int argc, char ** argv)
{
char a[] = "test2";
printf("sizeof(a): %lu\n", sizeof(a));
return 0;
}
[~]$ gcc -std=c99 -pedantic -Wall -o test test.c
[~]$ ./test
sizeof(a): 6
[~]$Re: A convenient untruth: Array notation in C is a lie
#74The 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…
[deleted]
Re: A convenient untruth: Array notation in C is a lie
#75Earlier quoted context omitted.
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…
I mean, int[5] and int[7] would be different types, and lots of bugs happen from passing something besides the appropriate array type to a function. That being said, most languages which disambiguate between int[5] and int[7] provide some kind of polymorphism (and usually store it as a struct of size + data, to enable that). For example: you can define a first function that goes from t[N]->t pretty easily, and it wou…
Right, in a language with dependent types there is a type-level difference between int[5] and int[7], but c is not such a language, therefore using a syntax that encourages the mistaken notion that there is a type-level difference between int[5] and int[7] would be misleading.
Re: A convenient untruth: Array notation in C is a lie
#76Earlier quoted context omitted.
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…
> 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. arr and arr2 are indeed distinct types. They are of type int[5] and int[7]. You can see this by checking that they have different sizes, or that `printf("%s\n", std::is_same ::value ? "true" : "false");` will…
Sizes aren't types though, and if I'm not mistaken that line of code is c++ no?
Re: A convenient untruth: Array notation in C is a lie
#77The thing to keep in mind is Never (Never) use array syntax in your function arguments. It implies something that you can't rely on. More on this: https://lkml.org/lkml/2015/9/3/428
Re: A convenient untruth: Array notation in C is a lie
#78The 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've heard this phrase - "declarations mirror use" many times before but it just doesn't click for me for some reason.
Who's use? The compiler's or the programmer's? Can you elaborate? Sorry if this silly question but I've scratched my head enough on hearing that phrase that I thought I would ask. Cheers.
Re: A convenient untruth: Array notation in C is a lie
#79Earlier quoted context omitted.
I think it's more likely the reaction to someone who uses magic languages that perform complicated actions over a simple assignment. If you think of C as a high-level assembly language whose assignment instruction is converted into a single machine instruction, this type of behavior is not so surprising.
> I think it's more likely the reaction to someone who uses magic languages that perform complicated actions over a simple assignment. If you think of C as a high-level assembly language whose assignment instruction is converted into a single machine instruction, this type of behavior is not so surprising. C assignment isn't that simple. Consider this program: #include struct point { int x; int y; }; int main(void) {…
That's just doing a copy of contiguous memory though? Sure, C has simple custom data types.
I like to think of it as one small step above assembly languages; it's certainly not a "portable assembly", but it's about as low as a high-level language can possibly be.
Re: A convenient untruth: Array notation in C is a lie
#80Earlier quoted context omitted.
> I think it's more likely the reaction to someone who uses magic languages that perform complicated actions over a simple assignment. If you think of C as a high-level assembly language whose assignment instruction is converted into a single machine instruction, this type of behavior is not so surprising. C assignment isn't that simple. Consider this program: #include struct point { int x; int y; }; int main(void) {…
That's just doing a copy of contiguous memory though? Sure, C has simple custom data types. I like to think of it as one small step above assembly languages; it's certainly not a "portable assembly", but it's about as low as a high-level language can possibly be.
Yes, C is definitely a low-level language, I was just responding to someone's inaccurate justification for why you can't copy arrays like that.