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

On 17/07/2024 13:38, Bart wrote:

On 13/07/2024 10:39, BGB wrote:
 

But, as I see it, no real point in arguing this stuff (personally, I have better stuff to be doing...).

 We all do. But this group seems to be about arguing about pointless stuff and you might come here when you want a respite from proper work.

I don't think that's the /only/ purpose of this group, but people like chatting about things that interest them even if they are not important.   And something might seem pointless to one person and important to another.

 However (here I assume you've gone back to Quake but that other interested parties might be reading this), consider the program below.
 That sets up an array and then sums its elements by calling 3 different functions to do the job:
 (1) Using normal C pass-by-value

Just to be clear - it is passing a pointer by value.  The array is not passed in any way.

 (2) Using C pass-by-value to emulate call-by-reference

This is identical to (1).  Both are passing a pointer by value, and both are emulating a limited type of pass by reference (limited in that the length of the array is not part of the passed parameter, but must be given independently).

 (3) Using fantasy true call-by-reference as it might appear if C had the
     feature

The fantasy matches C++ pretty closely - except you are making a reference to an unbound array of type T, not an actual array.

 (I'd hoped C++ would run this, but it didn't even like the middle function.)

It is fine in C++20 or C++23, but not in C++17 or before.  (If you want to know why, ask in comp.lang.c++, because I don't know the answer!)
But even in C++, you are not really referencing the array here - you are referencing an unbound (unsized) array, and there is no information about the real size.  It's somewhat like passing a pointer here (like function 1) by using a reference to the first element.  But you can't (in C++) use "sizeof A" here, and unlike the other functions, you can't pass a null pointer.
C++'s arrays are limited in functionality and features by compatibility with C, so you can't pass C-style arrays around in C++ because array expressions convert to pointer expressions in the same way as in C.  If you want the C++ version of arrays, use std::array<T, n> for fixed-size arrays or std::vector<T> for variable sized arrays.  These can be passed around into and out of functions, by value or reference, and have a selection of high-level methods and functions.  But that's all C++ rather than C.

 I'm asking people to compare the first and third functions and their calls, and to see if there's any appreciable difference between them. There will obviously be a difference in how the A parameter is declared.

The generated code (for gcc -x c++ -std=c++20) is the same for both, so there is no difference there.  Using the reference means you can't pass a null pointer, you can't pass a pointer to an individual int, and you can't use sizeof, so they are not entirely the same.  And as I wrote above, "sum_bytrueref" is not actually passing the array at all.
Both 1 and 3 give a reasonable emulation to passing the array by reference, but neither of them is actually doing so.

 ---------------------------------------------
#include <stdio.h>
 typedef int T;
 int sum_byvalue(T* A, int n) {
     int i, sum=0;
     for (i=0; i<n; ++i) sum += A[i];
     return sum;
}
 int sum_bymanualref(T(*A)[], int n) {
     int i, sum=0;
     for (i=0; i<n; ++i) sum += (*A)[i];
     return sum;
}
 int sum_bytrueref(T (&A)[], int n) {
     int i, sum=0;
     for (i=0; i<n; ++i) sum += A[i];
     return sum;
}
 int main(void) {
     enum {N = 10};
     T A[N] = {10,20,30,40,50,60,70,80,90,100};
     int total=0;
      total += sum_byvalue     (A, N);
     total += sum_bymanualref (&A, N);
     total += sum_bytrueref   (A, N);
      printf("%d\n", total);             // would show 1650
}
---------------------------------------------
 Find anything? I thought not.
 Those findings might suggest that C doesn't need call-by-reference, not for arrays anyway.

It is correct that C does not need pass by reference for arrays.  It does not need to be able to pass arrays at all.  This is clearly demonstrated by the fact that C does not have pass by reference, and cannot pass arrays at all, and yet has been used happily (and sometimes unhappily) for half a century.
The question is not if C /needs/ any of this, but if the language could be /improved/ by adding such features.  And I think that we all know that it would add very, very little of interest to the language unless arrays were changed to act like other object types.  And that would be a major and massively incompatible change to the language, so it's not going to happen.
That doesn't mean that supporting pass by reference and/or supporting arrays as first-class objects is not something that people might want in language X.  Nor does it mean that C programmers prefer C's way of doing things.  It is simply how C is, and programmers can work fine with C the way it is.

Except that at present you can do this:
      T x=42;
     sum_byvalue(&x, N);
 which would not be possible with call-by-reference. Nor with sum_bymanualref, but apparently nobody wants to be doing with all that extra, fiddly syntax. Better to be unsafe!

No, better to be safe.
But it doesn't make sense to make massive incompatible changes to a language to reduce the risk of one minor kind of error.  I really don't see that there is any more likelihood of passing the int "x" when you meant to pass the int array "xs", than there is of passing "ys" when you meant to pass "xs".
I'm all in favour of safety.  My preference, for more serious code, is C++ rather than C.  It doesn't just have a couple of extra bits that make some things look marginally safer, such as you are suggesting here, but has enough to make many things /actually/ safer.  So I'd use a std::array<> type that is a /real/ array object type, references that are /real/ pass by reference that includes the full type, and a syntax that makes it hard to get the details wrong:
template <size_t N>
constexpr auto sum_by_array(const std::array<T, N> &A) {
     auto sum = 0;
     for (auto x : A) {
         sum += x;
     }
     return sum;
}
I am not suggesting that C++ is for everyone - people make their choices of language for all kinds of reasons.  And std::array<> is not the answer for all C++ code either.  But for /me/, when I have fixed size arrays (and that is the norm for my code), I prefer std::array<> because it is safer and clearer.  (And as a bonus, the generated code is usually more efficient.)