Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?utf-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Sun, 18 Aug 2024 18:03:41 -0700
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <865xrxe32q.fsf@linuxsc.com>
References: <v66eci$2qeee$1@dont-email.me> <v6of96$2ekb0$1@dont-email.me> <v6ovfc$2hcpf$1@dont-email.me> <v6p4hf$2icph$1@dont-email.me> <v6qgpu$2t6p7$3@dont-email.me> <v6r33m$30grj$1@dont-email.me> <20240712154252.00005c2f@yahoo.com> <86o7717jj1.fsf@linuxsc.com> <v6ti10$3gru4$1@dont-email.me> <v78af7$1qkuf$1@dont-email.me> <20240717163457.000067bb@yahoo.com> <v78piu$1su4u$1@dont-email.me> <86a5hep45h.fsf@linuxsc.com> <v9ktep$v5sk$1@dont-email.me> <87y14xsvnh.fsf@bsb.me.uk> <v9l95b$10ogv$1@dont-email.me> <87sev5s51s.fsf@bsb.me.uk> <v9n6uj$1cvvg$2@dont-email.me> <87jzggss6h.fsf@bsb.me.uk> <v9nns5$1f74j$1@dont-email.me> <8734n1s7z8.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 19 Aug 2024 03:03:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8e0243d997a628e731b4ff9e397b6328";
	logging-data="2717539"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19oA20/5QbdoasLYkpGlbQTyXRpNu1CN4o="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:fxMG7MimHqzItDauBsKnFq1OIFo=
	sha1:5rXsHkMBCfJaS7eAf4Ylvtn5iAI=
Bytes: 4005

Ben Bacarisse <ben@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/08/2024 12:00, Ben Bacarisse wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 16/08/2024 02:08, Ben Bacarisse wrote:
>>>>
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> 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.
>>>>
>>>> In C++, you can't pass arrays as parameters at all - the language
>>>> inherited C's handling of arrays.  You can, of course, pass
>>>> objects of std::array<> type by value or by reference, just like
>>>> any other class types.
>>>
>>> The best way to think about C++ (in my very non-expert opinion) is
>>> to consider references as values that are passed by, err...,
>>> value.  But you seem prepared to accept that some things can be
>>> "passed by reference" in C++.
>>
>> That seems a subtle distinction - I'll have to think about it a
>> little.  I like your description of arguments being like local
>> variable initialisation - it makes sense equally well regardless of
>> whether the parameter is "int", "int*", or "int&".  (It's probably
>> best not to mention the other one in this group...)
>>
>>> So if this:
>>> #include <iostream>
>>> void g(int &i) { std::cout << i << "\n"; }
>>> int main(void)
>>> {
>>>     int I{0};
>>>     g(I);
>>> }
>>> shows an int object, I, being passed to g, why does this
>>> #include <iostream>
>>> void f(int (&ar)[10]) { std::cout << sizeof ar << "\n"; }
>>> int main(void)
>>> {
>>>     int A[10];
>>>     f(A);
>>> }
>>> not show an array, A, being passed to f?
>>
>> That's backwards compatibility with C array handling at play.
>
> I'm not sure how this answers my question.  Maybe you weren't
> answering it and were just making a remark...

My guess is he didn't understand the question.  The code shown
has nothing to do with backwards compatibility with C array
handling.