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

David Brown <david.brown@hesbynett.no> writes:

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:

...

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'm sorry I wasn't more clear.

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.

Ah.  Then is was an answer to the question you thought I was asking.

The trouble is, it never occurred to me you would not know that C++
array references behave just like all other references -- as aliases to
the objects they reference.  So I was asking for some explanation of how
you were using terms: "if this is 'passing an int', in what sense is this
not 'passing an array'?".

(I hope you don't think I'm being rude.  C++ is a gruesomely huge
language, littered with special cases and array reference must be almost
never used, especially now.  But I started with the first release of
Cfront, so I learned all the primitive bits first.  It's the new bits I
can't fathom.)

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++.

Well, it was little more like I thought you were maybe using the term
"passing by reference" is some way that I'd missed.  That's why I
started with a brief explanation of how I used to explain it.

--
Ben.