4 ms·

I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default

by knaq 6y ago

I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy) Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually want to pass by value. It works fine. I have frequently seen beginners struggle with C arrays and pointers. Part of the trouble is that you can't pass an array. You can try, but the compiler quietly substitutes different code. It's a source of confusion, generating incorrect mental models of what is going on.

brundolf 6y ago
Beginners don't struggle in Java, JavaScript, Python, C#, Ruby, and the dozen (at least) other languages that exclusively pass arrays by reference. But all of this is way off-topic from the OP: the original point was, "Passing a pointer and length separately is error-prone; there should be a way to easily package the two together and this should be the default pattern for 90% of cases." Then you came in and said "No, instead C should support this totally orthogonal side-case that's a bad idea 90% of the time but has some niche uses." It's not a bad suggestion in itself, necessarily, but it's totally unrelated to the original proposal, much less an alternative to it.
- knaq 6y ago
  The original claim was that the proposal would be C really passing arrays. In the article it says: "the inability to pass an array to a function as an array, even if it is declared to be an array. C will silently convert the array to be a pointer, and will rewrite the function declaration so it is semantically a pointer" ...and later, referring to the new syntax: "an array is passed" In no way is it so. It has nothing to do with passing arrays. It's passing a fat pointer, which is different.
erik_seaberg 6y ago
The weird thing is that the compiler obviously knows how to copy an array, because you can pass a copy of a struct that contains an array. I have a vague impression that early versions of C couldn't pass either structs or arrays, only scalars and pointers.
- hvdijk 6y ago
  You are correct. This is briefly mentioned on https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html: > While [the first edition of K&R] foreshadowed the newer approach to structures, only after it was published did the language support assigning them, passing them to and from functions, [...]
saagarjha 6y ago
> Are we having huge problems with structs being passed by value? Doing this frequently in any application means your profile will have a lot of memcpy in it.
- knaq 6y ago
  Yes, but is that happening? I think the answer is no. The mere ability to pass huge structures does not cause programmers to do that. I believe the same would be true if the language allowed passing arrays. Programmers would not generally pass them around. There is no need for the language to protect us from this by failing to implement the ability to pass arrays.
  - saagarjha 6y ago
    I think I agree with that position. I seem to have gotten the impression that you were doing this and not seeing a performance impact, which has been wrong in my experience.

by knaq 6y ago

brundolf 6y ago

Beginners don't struggle in Java, JavaScript, Python, C#, Ruby, and the dozen (at least) other languages that exclusively pass arrays by reference. But all of this is way off-topic from the OP: the original point was, "Passing a pointer and length separately is error-prone; there should be a way to easily package the two together and this should be the default pattern for 90% of cases." Then you came in and said "No, instead C should support this totally orthogonal side-case that's a bad idea 90% of the time but has some niche uses." It's not a bad suggestion in itself, necessarily, but it's totally unrelated to the original proposal, much less an alternative to it.

knaq 6y ago
The original claim was that the proposal would be C really passing arrays. In the article it says: "the inability to pass an array to a function as an array, even if it is declared to be an array. C will silently convert the array to be a pointer, and will rewrite the function declaration so it is semantically a pointer" ...and later, referring to the new syntax: "an array is passed" In no way is it so. It has nothing to do with passing arrays. It's passing a fat pointer, which is different.

erik_seaberg 6y ago

The weird thing is that the compiler obviously knows how to copy an array, because you can pass a copy of a struct that contains an array. I have a vague impression that early versions of C couldn't pass either structs or arrays, only scalars and pointers.

hvdijk 6y ago
You are correct. This is briefly mentioned on https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html: > While [the first edition of K&R] foreshadowed the newer approach to structures, only after it was published did the language support assigning them, passing them to and from functions, [...]

saagarjha 6y ago

> Are we having huge problems with structs being passed by value? Doing this frequently in any application means your profile will have a lot of memcpy in it.

knaq 6y ago
Yes, but is that happening? I think the answer is no. The mere ability to pass huge structures does not cause programmers to do that. I believe the same would be true if the language allowed passing arrays. Programmers would not generally pass them around. There is no need for the language to protect us from this by failing to implement the ability to pass arrays.
- saagarjha 6y ago
  I think I agree with that position. I seem to have gotten the impression that you were doing this and not seeing a performance impact, which has been wrong in my experience.