Re: technology discussion → does the world need a "new" C ?

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.