Liste des Groupes | Revenir à cl c |
On 16/08/2024 09:04, David Brown wrote:Yes. That has never been in doubt - I've agreed to it all along, as has everyone else. But "similar to" does not mean "the same as".On 15/08/2024 18:08, Bart wrote:So, you agree that it is similar to.
>These were my original comments on the subject made to DB:>
>
>
DB:
>. In C, there is no "pass by reference" or "return by reference". It is all done by value.
>
BC:
>
>Arrays are passed by reference:
>
> void F(int a[20]) {}
>
> int main(void) {
> int x[20];
> F(x);
> }
>
> Although the type of 'a' inside 'F' will be int* rather than int(*)[20].
>
It was in reply to DB which appear to imply that arrays were passed by value. Obviously they're not passed by value, so what then? (Please, don't rerun the thread! This is where everyone jumped in.)
>
I am not sure if you want an answer here or not - you asked "so what then", but also asked to avoid a re-run of the thread.
>
I can give a summary - and I also hope this doesn't lead to a re-run of the discussion. However, since you are asking the same question as you did at the start, and the language C has not changed in the meantime, the factual and correct answers will inevitably be the same:
>
1. C has no "pass by reference" - it is all "pass by value".
>
2. In C, you cannot pass an array as a function parameter.
>
3. The automatic conversion of many array expressions to pointer expressions, along with the similar conversions of function parameter types, gives C users a syntax that is similar - but not identical to - what you would have if the language supported passing arrays by reference.
And not just the resulting syntax, but the semantics and even the generated code can be the same (as I demonstrated but somebody complained).They /can/ be the same - and they can be different. If C could pass arrays as parameters (it can't), and if it had pass by reference (it doesn't), then "sizeof" would give the size of the array passed, not the size of a pointer. The type of the parameter would be an array type, not a pointer. So while the semantics and expected generated code will be the same for some functions, it will be different for other functions. Hence, "similar to", and not "the same as".
Would you agree that they are effectively passed by-reference for all practical purposes?No.
All the other differences in detail are mostly due to the weird way that C handles arrays anyway.Well, yes. (Though the "details" are important.) But if C did not handle arrays in that way, there'd be other issues. You might be able to pass arrays by value, but you'd still not be able to pass them by reference. And now a function that takes an array of 10 int's is completely different from a function that takes an array of 20 int's.
Cheap and cheerful approaches are fine for cheap and cheerful languages. You don't have to think about the implications of such changes, or corner cases, or what other people think, or how it could affect existing code, or how to document or teach it.4. Adding "pass by reference" and "arrays as first class objects" would both be very significant changes to CAdding pass-by-reference would not be a huge change. I added that using a cheap and cheerful approach that seems work well enough (a parameter marked as by-ref, would have '&' automatically applied on arguments, and '*' automatically applied to parameter accesses in the callee**).
But what would complicate it in C is how it interacts with how arrays currently work. For example, passing array A already passes '&A[0]'; it can't really pass '&&A[0]' if it's marked as being by-reference!
(** There were some side-effects: while you can pass a char or short to an int parameter for example and it will promote it, if the int is by-reference, you can only pass an exact int type. And also, I wasn't able to apply default values to optional by-reference parameters.)
Les messages affichés proviennent d'usenet.