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

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.