Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?UTF-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Mon, 19 Aug 2024 12:22:08 +0300
Organization: A noiseless patient Spider
Lines: 115
Message-ID: <20240819122208.000010d3@yahoo.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>
	<865xrxe32q.fsf@linuxsc.com>
	<v9us3n$2pl3p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Aug 2024 11:21:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="63e4d7165886f0c08d939b274e907ed0";
	logging-data="2954274"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+zNYsxc4XUDWAwXVPks2AAESdZOJzpois="
Cancel-Lock: sha1:61foY7FghQuL+OJXhy8pii4Uyak=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 6801

On Mon, 19 Aug 2024 09:26:46 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 19/08/2024 03:03, Tim Rentsch wrote:
> > 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.  
> 
> I had intended to make a brief remark and thought that was all that
> was needed to answer the question.  But having thought about it a bit
> more (prompted by these last two posts), and tested the code (on the 
> assumption that the gcc writers know the details better than I do),
> you are correct - I did misunderstand the question.  I was wrong in
> how I thought array reference parameters worked in C++, and the way
> Ben worded the question re-enforced that misunderstanding.
> 
> I interpreted his question as saying that the code "f" does not show
> an array type being passed by reference, with the implication that
> the "sizeof" showed the size of a pointer, not the size of an array
> of 10 ints, and asking why C++ was defined that way.  The answer, as
> I saw it, was that C++ made reference parameters to arrays work much
> like pointer parameters to arrays, and those work like in C for
> backwards compatibility.
> 
> Of course, it turns out I was completely wrong about how array type 
> reference parameters work in C++.  It's not something I have had use
> for in my own C++ programming or something I have come across in
> other code that I can remember, and I had made incorrect assumptions
> about it.  Now that I corrected that, it all makes a lot more sense.
> 
> And so I presume Ben was actually asking why I /thought/ this was not 
> passing an array type (thus with its full type information, including 
> its size).  Then answer there is now obvious - I thought that because
> I had jumped to incorrect conclusions about array reference
> parameters in C++.
> 
> So thank you (Ben and Tim) for pushing me to correct my C++ 
> misunderstanding here, and apologies to anyone confused by my mistake.
> 
> 

In this particular case C++ behaves very similarly to non-extended
Pascal as described in "PASCAL User Manual and Report". 
It treats size of array as part of the type.

I am not sure that description of observed compiler's behavior as
"passing an array type with its full type information, including
its size" is a correct one. Or, may be, it is formally correct, but not
enlightening. IMHO, the better description is that
compiler does strict type checks  at caller site that among other things
include checks of the size of the array.