Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.c Subject: Re: technology discussion =?utf-8?Q?=E2=86=92?= does the world need a "new" C ? Date: Fri, 16 Aug 2024 01:08:15 +0100 Organization: A noiseless patient Spider Lines: 200 Message-ID: <87sev5s51s.fsf@bsb.me.uk> References: <87ikxconq4.fsf@bsb.me.uk> <20240711115418.00001cdf@yahoo.com> <20240712154252.00005c2f@yahoo.com> <86o7717jj1.fsf@linuxsc.com> <20240717163457.000067bb@yahoo.com> <86a5hep45h.fsf@linuxsc.com> <87y14xsvnh.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 16 Aug 2024 02:08:15 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e2d864991417c23f00812fb2ef3e1b2b"; logging-data="1199306"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+uZ62NT/6ByFGQGBgrX0bKSh+zg/nDVJ0=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:96dBFwVBNdygU9mUD2rALBYCifE= sha1:bz4r3YCk4iG+3H+RMwX62O1mXLM= X-BSB-Auth: 1.7bac07d339c46b84d580.20240816010815BST.87sev5s51s.fsf@bsb.me.uk Bytes: 9652 Bart writes: > On 15/08/2024 15:33, Ben Bacarisse wrote: >> Bart writes: >> >>> On 15/08/2024 09:43, Tim Rentsch wrote: >>>> Bart writes: > >>>> C call-by-value call-by-reference >>>> =============== ================= >>>> at call: >>>> >>>> (array argument) F(A) H(A) >>>> >>>> (pointer argument) F(p) (disallowed) >>> >>> My posts were about passing *arrays* and the fact that C's pass-by-value >>> was remarkably similar to pass-by-reference. >> Which is why, presumably, you didn't show the differences. Your >> post was all polemic not part of a collegiate discussion of the >> similarities and differences. >> >>> However your entry for pointers is not correct: >> No, the entry is correct. H(p) would be (is?) disallowed when H's >> parameter is a reference to an array. > > Sorry, what language does the right-hand column pertain to? /Any/ language > that has call-by-reference, or Tim's hypthetical language? Tim said that case was "disallowed". You call that an error on his part. What language did you have in mind that permits such a gross warping of types? I would describe /any/ language that allowed it as having a design error. > Or any that could be used to prove him right? > > In general there is no reason, in a language with true call-by-reference, > why any parameter type T (which has the form U*, a pointer to anything), > cannot be passed by reference. It doesn't matter whether U is an array type > or not. I can't unravel this. Take, as a concrete example, C++. You can't pass a pointer to function that takes an array passed by reference. You can, of course, pass a pointer by reference, but that is neither here nor there. >>> you can pass pointers by >>> reference (in C, it means passing a T** type instead of T* to emulate >>> that). >> H's parameter is /not/ what you claim "emulates" a reference to a >> pointer -- it's a hypothetical reference to an array. > > In my original post it was G() that was C emulating pass-by-reference. > > It wasn't stated that p was an array pointer, only pointer, but it doesn't > make any difference in H which we can assume is not C, and therefore > doesn't have C's hangups about arrays and pointers. The whole point if Tim's post was to point out how call-by-reference would be significantly different to what C has right now. That requires imaging "C with call-by-reference". >> Maybe you missed what Tim was doing. He is showing a fuller comparison >> for one F and one H. A different function could, in this hypothetical >> C with call-by-reference, be passed a pointer, but then it could not be >> passed an array. > > Neither of you have explained this well. Are you both projecting C's > craziness with arrays and pointers onto this hypothetical language? > > If so, then if this fantasy language has true pass-by-reference, then let > it have real value-arrays too! It might, but it would be closer to C if it did not. And C++ is not a fantasy language but it has reference parameters that behave as illustrated. >>>> (null argument) F(0) (disallowed) >>> >>> Pass-by-reference necessarily requires an lvalue at the call-site >> Yes, that is one of the differences you failed to illustrate. > > I illustrated some conveniences which C's array-passing idiom which match > those of true pass-by-reference. > > >>> since it effectively applies & to the argument. >> No. Passing a reference is /not/ like using & to pass a pointer. > > Funny, in my language that is EXACTLY how it is implemented. Instead of my > writing: > > F(&x) and in F having to write: *x > > you instead write: > > F(x) and in F you write: x Your whole point (which to some extent I accept) is that what the user writes is what matters. Passing a reference is /not/ like using & to pass a pointer. > So it will insert & and * operators for you. Why, how would /you/ do it? > (I'm talking about this level of language; higher level ones might do > everthing with references anyway, and might not have & or * operators.) > > > >>>> inside function: >>>> >>>> (access) A[i] A[i] >>>> >>>> (update) A[i] = ... A[i] = ... >>>> >>>> sizeof A (pointer size) (array size) >>> >>> That's one of the small differences. But you only get the array size in a >>> language where the array type includes its length. Otherwise, you only get >>> it if it's part of the parameter type. >>> >>>> A++ (changes A variable) (disallowed) >>> >>> (In my language ++A is allowed. I'm not sure why, it's likely a bug.) >> In the hypothetical C with call-by-reference, it's another difference >> you chose not to show. > > Yes, as I said, I concentrate on the ones which allowed you to write F(A), > and A[i] inside F, just like pass-by-reference, rather than F(&A), and > (*A[i]) inside F. Did I claim it was full by pass-by-reference? > >>>> A = (new value) (changes A variable) (disallowed) >>> >>> This is allowed too in my language, if the array has a fixed size. It >>> reassigns the whole array. >> Your language (for which we have no reference material) is beside the >> point. This is another difference you failed to point out in your >> comparison > > It doesn't matter; any call-by-reference worth its salt will allow you to > change variables in the caller. That's half the point it! C with call-by-reference should treat array references just like C arrays. A reference should behave like the thing it references. > C doesn't have A=B syntax for arrays, but it can do memcpy for the same > effect. > > >> >>> In C you can't do A = B for other reasons, since arrays aren't manipulated >>> by value. >> One way or another, this is a difference you failed to illustrate. If >> this hypothetical C is very close to C then the difference is as Tim >> posted. But in a another quasi-C that permits array assignment there >> would still be a difference: the pointer assignment would be disallowed >> but the array assignment (by reference) would be permitted. > > What pointer assignment? You're mixing actual C with fantasy C. You can't > do that: if you add array assignment to C, then it changes everything. Indeed, but you brought up assignable arrays in your language so I wanted to show how, even in such an extended C, it remains a difference you were glossing over. >> So why did you give only one side of the comparison? You have nothing >> to lose by being open about the differences if your objective is an >> open, collegiate discussion of C. By presenting a polemic, you make the >> whole exchange more antagonistic than it needs to be. > ========== REMAINDER OF ARTICLE TRUNCATED ==========