>>>>> standard.
>>>>>
> * Whole-program compilers
> * 64-bit everything (C is still stuck on 32-bits)
> * Super-fast compilers ...
Who says
C is stuck is 32 bits?

Am 02.03.2022 um 12:17 schrieb Malcolm McLean:
> On Wednesday, 2 March 2022 at 04:47:07 UTC, Bonita Montero wrote:
>> Am 02.03.2022 um 05:45 schrieb Lynn McGuire:
>>> On 2/28/2022 11:44 AM, Bonita Montero wrote:
>>>> Am 28.02.2022 um 17:43 schrieb Amine Moulay Ramdane:
>>>>> Hello,
>>>>>
>>>>>
>>>>> Linus Torvalds prepares to move the Linux kernel to modern C
>>>>>
>>>>> The Linux kernel's foundation is the ancient C89 standard of C. Now,
>>>>> Torvalds has decided to upgrade to 2011's more modern C11 standard.
>>>>>
>>>>> Read more here:
>>>>>
>>>>> https://www.zdnet.com/article/linus-torvalds-prepares-to-move-the-linux-kernel-to-modern-c/?ftag=COS-05-10aaa0h&utm_campaign=trueAnthem%3A%20Trending%20Content&utm_medium=trueAnthem&utm_source=facebook&fbclid=IwAR1oF1ysACG28YRYJnnYlt7oCzfRhXSUePOKd4xsycb3F8GGwxIfeAXZI8Y
>>>>>
>>>>>
>>>>>
>>>>> Thank you,
>>>>> Amine Moulay Ramdane.
>>>>
>>>> C isn't a modern language, no matter which standard.
>>>
>>> What is your definition of a modern language ?
>> OOP, RAII, generic programming, functional programming,
>> proper error-handling like with exceptions.
>>
> That's fair enough. With the exception of functional programming, these have all been
> introduced since C was first developed.

There's no OOP, no RAII, no usable generic proigramming
and no proper error-handling.

> You can argue about the benefits. Especially in C++, where these ideas have to be
> bolted onto an existing language rather than implemented in a consistent way in
> the basic design.

C++ isn't easy to handle for someone working with it just for
some weeks, but it is magnitudes more powerful.

Am 02.03.2022 um 14:47 schrieb Bart:
> On 02/03/2022 04:46, Bonita Montero wrote:
>> Am 02.03.2022 um 05:45 schrieb Lynn McGuire:
>>> On 2/28/2022 11:44 AM, Bonita Montero wrote:
>>>> Am 28.02.2022 um 17:43 schrieb Amine Moulay Ramdane:
>>>>> Hello,
>>>>>
>>>>>
>>>>> Linus Torvalds prepares to move the Linux kernel to modern C
>>>>>
>>>>> The Linux kernel's foundation is the ancient C89 standard of C.
>>>>> Now, Torvalds has decided to upgrade to 2011's more modern C11
>>>>> standard.
>>>>>
>>>>> Read more here:
>>>>>
>>>>> https://www.zdnet.com/article/linus-torvalds-prepares-to-move-the-linux-kernel-to-modern-c/?ftag=COS-05-10aaa0h&utm_campaign=trueAnthem%3A%20Trending%20Content&utm_medium=trueAnthem&utm_source=facebook&fbclid=IwAR1oF1ysACG28YRYJnnYlt7oCzfRhXSUePOKd4xsycb3F8GGwxIfeAXZI8Y
>>>>>
>>>>>
>>>>>
>>>>> Thank you,
>>>>> Amine Moulay Ramdane.
>>>>
>>>> C isn't a modern language, no matter which standard.
>>>
>>> What is your definition of a modern language ?
>>
>> OOP, RAII, generic programming, functional programming,
>> proper error-handling like with exceptions.
>
> They all sound like things designed to make coding harder and less
> accessible.

No, it's the opposite. They make code much more readable
and you're a magnitude more productive.

Am 02.03.2022 um 15:42 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 02.03.2022 um 05:45 schrieb Lynn McGuire:
>>> On 2/28/2022 11:44 AM, Bonita Montero wrote:
>>>> Am 28.02.2022 um 17:43 schrieb Amine Moulay Ramdane:
>>>>> Hello,
>>>>>
>>>>>
>>>>> Linus Torvalds prepares to move the Linux kernel to modern C
>>>>>
>>>>> The Linux kernel's foundation is the ancient C89 standard of C. Now,
>>>>> Torvalds has decided to upgrade to 2011's more modern C11 standard.
>>>>>
>>>>> Read more here:
>>>>>
>>>>> https://www.zdnet.com/article/linus-torvalds-prepares-to-move-the-linux-kernel-to-modern-c/?ftag=COS-05-10aaa0h&utm_campaign=trueAnthem%3A%20Trending%20Content&utm_medium=trueAnthem&utm_source=facebook&fbclid=IwAR1oF1ysACG28YRYJnnYlt7oCzfRhXSUePOKd4xsycb3F8GGwxIfeAXZI8Y
>>>>>
>>>>>
>>>>>
>>>>> Thank you,
>>>>> Amine Moulay Ramdane.
>>>>
>>>> C isn't a modern language, no matter which standard.
>>>
>>> What is your definition of a modern language ?
>>
>> OOP,
>
> Simula, 1967.
>
>
>> RAII,
>
> ADA, 1980.
>
>> generic programming,
>
> ML, 1973.
>
>> functional programming,
>
> Lisp, 1970's.

We're talking about C++ vs. C.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 02.03.2022 um 15:42 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 02.03.2022 um 05:45 schrieb Lynn McGuire:
>>>> On 2/28/2022 11:44 AM, Bonita Montero wrote:
>>>>> Am 28.02.2022 um 17:43 schrieb Amine Moulay Ramdane:
>>>>>> Hello,
>>>>>>
>>>>>>
>>>>>> Linus Torvalds prepares to move the Linux kernel to modern C
>>>>>>
>>>>>> The Linux kernel's foundation is the ancient C89 standard of C. Now,
>>>>>> Torvalds has decided to upgrade to 2011's more modern C11 standard.
>>>>>>
>>>>>> Read more here:
>>>>>>
>>>>>> https://www.zdnet.com/article/linus-torvalds-prepares-to-move-the-linux-kernel-to-modern-c/?ftag=COS-05-10aaa0h&utm_campaign=trueAnthem%3A%20Trending%20Content&utm_medium=trueAnthem&utm_source=facebook&fbclid=IwAR1oF1ysACG28YRYJnnYlt7oCzfRhXSUePOKd4xsycb3F8GGwxIfeAXZI8Y
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>> Amine Moulay Ramdane.
>>>>>
>>>>> C isn't a modern language, no matter which standard.
>>>>
>>>> What is your definition of a modern language ?
>>>
>>> OOP,
>>
>> Simula, 1967.
>>
>>
>>> RAII,
>>
>> ADA, 1980.
>>
>>> generic programming,
>>
>> ML, 1973.
>>
>>> functional programming,
>>
>> Lisp, 1970's.

> We're talking about C++ vs. C.

Lesen sie besser.

"What is your definition of a modern language"

Am 02.03.2022 um 19:33 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 02.03.2022 um 15:42 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 02.03.2022 um 05:45 schrieb Lynn McGuire:
>>>>> On 2/28/2022 11:44 AM, Bonita Montero wrote:
>>>>>> Am 28.02.2022 um 17:43 schrieb Amine Moulay Ramdane:
>>>>>>> Hello,
>>>>>>>
>>>>>>>
>>>>>>> Linus Torvalds prepares to move the Linux kernel to modern C
>>>>>>>
>>>>>>> The Linux kernel's foundation is the ancient C89 standard of C. Now,
>>>>>>> Torvalds has decided to upgrade to 2011's more modern C11 standard.
>>>>>>>
>>>>>>> Read more here:
>>>>>>>
>>>>>>> https://www.zdnet.com/article/linus-torvalds-prepares-to-move-the-linux-kernel-to-modern-c/?ftag=COS-05-10aaa0h&utm_campaign=trueAnthem%3A%20Trending%20Content&utm_medium=trueAnthem&utm_source=facebook&fbclid=IwAR1oF1ysACG28YRYJnnYlt7oCzfRhXSUePOKd4xsycb3F8GGwxIfeAXZI8Y
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Amine Moulay Ramdane.
>>>>>>
>>>>>> C isn't a modern language, no matter which standard.
>>>>>
>>>>> What is your definition of a modern language ?
>>>>
>>>> OOP,
>>>
>>> Simula, 1967.
>>>
>>>
>>>> RAII,
>>>
>>> ADA, 1980.
>>>
>>>> generic programming,
>>>
>>> ML, 1973.
>>>
>>>> functional programming,
>>>
>>> Lisp, 1970's.
>
>> We're talking about C++ vs. C.
>
> Lesen sie besser.
>
> "What is your definition of a modern language"

>> C isn't a modern language, no matter which standard.

> What is your definition of a modern language ?

That's C++ vs. C.
And it doesn't matter who came first. C++ is the only language
which combines nearly all of that features with the least possible
overhead (except thrown exceptions, but that's not significant for
the code).

On 02/03/2022 17:37, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 02/03/2022 04:46, Bonita Montero wrote:
>
>>> OOP, RAII, generic programming, functional programming,
>>> proper error-handling like with exceptions.
>>
>> They all sound like things designed to make coding harder and less
>> accessible.
>
> OK, I'll bite. Why would you not want type-generic functions? You have
> an array and you want the maximum. Why write max (and probably the
> array scanning) again and again just because sometimes it's an array of
> int and sometimes an array of struct date?

It's an idea that sounds good on paper, but look at how C++ does it for
example, where I believe they are implemented via templates. Need I say
more? But then C++ always seems to make a dog's dinner out of any feature.

Then, by being present in the language, people like to use them
everywhere and for everything. Since templates work with source code, it
means libraries making extensive use of them, slowing down compilation.

(I wouldn't mind doing a better implementation myself, but for me not
it's not a requirement that comes up often. It's easie to just have 2-3
versions of that 6-line function.)

> And then, since lots of operations are just array reductions based on
> some binary operation, why write that again and again? Functional
> languages let you express the pattern once and for all so that
>
> list_max(l) = reduce_using(max, l)
> list_min(l) = reduce_using(min, l)
> list_sum(l) = reduce_using(+, l)
> list_product(l) = reduce_using(*, l)

There are some nice ideas in FP but overall they are much harder to code
in for ordinary people, not helped by doing away with fundamentals such
as mutable variables, or loops.

Note that with 'generics', I'm talking about a feature where you write
one body of code, and that is instantiated multiple times, using
dedicated code for each type combination.

Another way of doing it is with dynamic or variant types, where the
/same/ body of code is executed even for different types. This is common
in scripting code, but it's also slower.

(This is how I deal with such things. I don't have built-in reduce, so
one was knocked up (see below), then this stuff is easy:

println reduce((max), (10,50,30,20,40)) # (max is built-in op)
println reduce((max), (1e100'000'000L, 1e-100'000'000L))
println reduce((max), ("BART"))
println reduce((+), ("One","Two","Three"))

Output is:

50
1.0e100000000
T
OneTwoThree

Creating 'list_max' etc is trivial. Note that you don't even need to be
aware of generics; it Just Works.

I'm currently incorporating such a dynamic type system into my systems
language.)

--------------
function reduce(op, L)=
case L.len
when 0 then
void
when 1 then
head(L) # borrowed from Haskell...
else
x:=head(L)
forall y in tail(L) do
x:=mapss(op, x,y)
od
x
esac
end

> Then, by being present in the language, people like to use them
> everywhere and for everything. Since templates work with source code, it
> means libraries making extensive use of them, slowing down compilation.

The higher productivity outweighs this my magnitudes.

On 3/2/2022 10:39 AM, Bonita Montero wrote:
> Am 02.03.2022 um 19:33 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 02.03.2022 um 15:42 schrieb Scott Lurndal:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>> Am 02.03.2022 um 05:45 schrieb Lynn McGuire:
>>>>>> On 2/28/2022 11:44 AM, Bonita Montero wrote:
>>>>>>> Am 28.02.2022 um 17:43 schrieb Amine Moulay Ramdane:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>>
>>>>>>>> Linus Torvalds prepares to move the Linux kernel to modern C
>>>>>>>>
>>>>>>>> The Linux kernel's foundation is the ancient C89 standard of C.
>>>>>>>> Now,
>>>>>>>> Torvalds has decided to upgrade to 2011's more modern C11 standard.
>>>>>>>>
>>>>>>>> Read more here:
>>>>>>>>
>>>>>>>> https://www.zdnet.com/article/linus-torvalds-prepares-to-move-the-linux-kernel-to-modern-c/?ftag=COS-05-10aaa0h&utm_campaign=trueAnthem%3A%20Trending%20Content&utm_medium=trueAnthem&utm_source=facebook&fbclid=IwAR1oF1ysACG28YRYJnnYlt7oCzfRhXSUePOKd4xsycb3F8GGwxIfeAXZI8Y
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Amine Moulay Ramdane.
>>>>>>>
>>>>>>> C isn't a modern language, no matter which standard.
>>>>>>
>>>>>> What is your definition of a modern language ?
>>>>>
>>>>> OOP,
>>>>
>>>> Simula, 1967.
>>>>
>>>>
>>>>> RAII,
>>>>
>>>> ADA, 1980.
>>>>
>>>>> generic programming,
>>>>
>>>> ML, 1973.
>>>>
>>>>> functional programming,
>>>>
>>>> Lisp, 1970's.
>>
>>> We're talking about C++ vs. C.
>>
>> Lesen sie besser.
>>
>> "What is your definition of a modern language"
>
>
>
> >> C isn't a modern language, no matter which standard.
>
> > What is your definition of a modern language ?
>
> That's C++ vs. C.

Agreed. C++ is more "modern" than C for sure.

> And it doesn't matter who came first. C++ is the only language
> which combines nearly all of that features with the least possible
> overhead (except thrown exceptions, but that's not significant for
> the code).

On 02/03/2022 18:06, rthiebaud wrote:
>>>>>> standard.
>>>>>>
>> * Whole-program compilers
>> * 64-bit everything (C is still stuck on 32-bits)
>> * Super-fast compilers ...
>  Who says
> C is stuck is 32 bits?

It just is. While versions with 64-bit ints might be knocking about,
generally they have to be compatible with what C already does on a given
platform. And that usually means int = 32 bits.

So, while people can choose to use long long int or int64_t, they have
to explicity state that everywhere, because:

12345 is int32
'A' is int32
short a,b,c;
a*b*c is int32 (so could overflow)
%d means int32 format
sprintf returns int32
f(){} defaults to int32 return type
int64_t a,b;
a && b is int32
!a is int32
enum E {a=5000000000};
enum E xx; is int32 (int64 on some compilers with extensions)

etc

Bart <bc@freeuk.com> writes:

> On 02/03/2022 17:37, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 02/03/2022 04:46, Bonita Montero wrote:
>>
>>>> OOP, RAII, generic programming, functional programming,
>>>> proper error-handling like with exceptions.
>>>
>>> They all sound like things designed to make coding harder and less
>>> accessible.
>>
>> OK, I'll bite. Why would you not want type-generic functions? You have
>> an array and you want the maximum. Why write max (and probably the
>> array scanning) again and again just because sometimes it's an array of
>> int and sometimes an array of struct date?
>
> It's an idea that sounds good on paper,

And in practice.

> but look at how C++ does it for example, where I believe they are
> implemented via templates. Need I say more?

Yes, you should have said you don't like C++ templates up front.
Instead, you made a sweeping statement to hook naive people like me into
discussing it.

--
Ben.

Show me sth. powerful like the following in any other language:

#include <iostream>
#include <type_traits>
#include <utility>
#include <tuple>

template<typename FirstArg, typename ... Args>
requires (sizeof ... (Args) == 0 || (std::is_convertible_v<Args,
FirstArg> && ...))
constexpr FirstArg multi_max( FirstArg firstArg, Args const &... args )
{ using namespace std;
FirstArg &max = firstArg;
auto findMax = [&]<size_t ... Is>( index_sequence<Is ...> iseq,
tuple<Args ...> tArgs )
{
((max = (FirstArg)get<Is>( tArgs ) > max ? (FirstArg)get<Is>( tArgs )
: max), ...);
};
findMax( make_index_sequence<sizeof ... (Args)>(), make_tuple( args ...
) );
return max;
}

On 02/03/2022 20:00, Bart wrote:
> On 02/03/2022 17:37, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 02/03/2022 04:46, Bonita Montero wrote:
>>
>>>> OOP, RAII, generic programming, functional programming,
>>>> proper error-handling like with exceptions.
>>>
>>> They all sound like things designed to make coding harder and less
>>> accessible.
>>
>> OK, I'll bite.  Why would you not want type-generic functions?  You have
>> an array and you want the maximum.  Why write max (and probably the
>> array scanning) again and again just because sometimes it's an array of
>> int and sometimes an array of struct date?
>
>
> It's an idea that sounds good on paper, but look at how C++ does it for
> example, where I believe they are implemented via templates. Need I say
> more? But then C++ always seems to make a dog's dinner out of any feature.
>

auto list_max(const auto& xs)
{ auto m = xs[0];
for (auto x : xs) {
m = (m > x) ? m : x;
}
return m;
}

Yes, that's clearly a dog's dinner.

The older (and still perfectly good) explicit template syntax is not
exactly difficult either :

template<typename T>
T list_max1(const T& xs)
{ auto m = xs[0];
for (auto x : xs) {
m = (m > x) ? m : x;
}
return m;
}

(Of course, there are already standard library functions to find the
maximum of a container.)

> Then, by being present in the language, people like to use them
> everywhere and for everything. Since templates work with source code, it
> means libraries making extensive use of them, slowing down compilation.
>

Big template libraries /do/ take a lot of effort to compile - you are
correct there. That's why modules are being added to the language. (It
would have been nice to have had modules a couple of decades ago, but
better late than never.)

>
>> And then, since lots of operations are just array reductions based on
>> some binary operation, why write that again and again?  Functional
>> languages let you express the pattern once and for all so that
>>
>>   list_max(l)     = reduce_using(max, l)
>>   list_min(l)     = reduce_using(min, l)
>>   list_sum(l)     = reduce_using(+,   l)
>>   list_product(l) = reduce_using(*,   l)
>

For your convenience, this is it in C++ (again, there are standard
library functions that could be used) :

auto reduce_using(auto f, auto & xs) {
auto m = xs[0];
for (auto x : xs) {
m = f(m, x);
}
return m;
}

auto list_max(const auto & xs) {
return reduce_using(
[](auto a, auto b) { return (a > b) ? a : b; },
xs);
}

A slightly nicer (IMHO) functional programming style would have :

list_max = reduce_using(max)

where "reduce_using" returns a function. "list_max" is then called with
a list, in the same way. In C++, that would be:

auto reduce_using(auto f) {
return [f](const auto & xs) {
auto m = xs[0];
for (auto x : xs) {
m = f(m, x);
}
return m;
};
}

auto list_max = reduce_using([](auto a, auto b)
{ return (a > b) ? a : b; });

(All these variants give the same object code from gcc.)

> There are some nice ideas in FP but overall they are much harder to code
> in for ordinary people, not helped by doing away with fundamentals such
> as mutable variables, or loops.

Mutable variables and loops are not fundamentals to programming - they
are fundamentals to /imperative/ programming. Functional programming
looks odd to people who have done nothing but imperative programming for
years. Imperative programming looks equally odd to people who have done
nothing but functional programming for years.

Imperative programming is a bit like cooking recipes - it's a series of
commands. Functional programming is more like mathematics, with a
series of definitions. Each has their advantages and disadvantages -
and thus many bigger programming languages support at least some aspects
of both styles.

>
> Note that with 'generics', I'm talking about a feature where you write
> one body of code, and that is instantiated multiple times, using
> dedicated code for each type combination.
>

Yes, I think that was clear. It is also known as early binding, or
compile-time generics.

> Another way of doing it is with dynamic or variant types, where the
> /same/ body of code is executed even for different types. This is common
> in scripting code, but it's also slower.

Indeed - also known as late binding or dynamic binding.

As usual, there are pros and cons to both systems.

>
> (This is how I deal with such things. I don't have built-in reduce, so
> one was knocked up (see below), then this stuff is easy:
>
>     println reduce((max), (10,50,30,20,40))       # (max is built-in op)
>     println reduce((max), (1e100'000'000L, 1e-100'000'000L))
>     println reduce((max), ("BART"))
>     println reduce((+),   ("One","Two","Three"))
>
> Output is:
>
>    50
>    1.0e100000000
>    T
>    OneTwoThree
>
> Creating 'list_max' etc is trivial. Note that you don't even need to be
> aware of generics; it Just Works.
>
> I'm currently incorporating such a dynamic type system into my systems
> language.)
>
> --------------
>     function reduce(op, L)=
>         case L.len
>         when 0 then
>             void
>         when 1 then
>             head(L)    # borrowed from Haskell...
>         else
>             x:=head(L)
>             forall y in tail(L) do
>                 x:=mapss(op, x,y)
>             od
>             x
>         esac
>     end
>
>

That's a perfectly reasonable way to handle this.

But it is not any more or less "trivial" than the C++ code or Haskell
code. The details are different, but not the principles.

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

> On 02/03/2022 20:00, Bart wrote:
>> On 02/03/2022 17:37, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 02/03/2022 04:46, Bonita Montero wrote:
>>>
>>>>> OOP, RAII, generic programming, functional programming,
>>>>> proper error-handling like with exceptions.
>>>>
>>>> They all sound like things designed to make coding harder and less
>>>> accessible.
>>>
>>> OK, I'll bite.  Why would you not want type-generic functions?  You have
>>> an array and you want the maximum.  Why write max (and probably the
>>> array scanning) again and again just because sometimes it's an array of
>>> int and sometimes an array of struct date?
>>
>>
>> It's an idea that sounds good on paper, but look at how C++ does it for
>> example, where I believe they are implemented via templates. Need I say
>> more? But then C++ always seems to make a dog's dinner out of any feature.
>
> auto list_max(const auto& xs)
> {
> auto m = xs[0];
> for (auto x : xs) {
> m = (m > x) ? m : x;
> }
> return m;
> }
>
> Yes, that's clearly a dog's dinner.

Not everyone will be 100% happy with it. What if the xs are huge
objects -- are they being copied and will that all that be optimised
away? (I think I know the answers -- those are rhetorical questions.)

>>> And then, since lots of operations are just array reductions based on
>>> some binary operation, why write that again and again?  Functional
>>> languages let you express the pattern once and for all so that
>>>
>>>   list_max(l)     = reduce_using(max, l)
>>>   list_min(l)     = reduce_using(min, l)
>>>   list_sum(l)     = reduce_using(+,   l)
>>>   list_product(l) = reduce_using(*,   l)
>>
>
> For your convenience, this is it in C++ (again, there are standard
> library functions that could be used) :
>
> auto reduce_using(auto f, auto & xs) {
> auto m = xs[0];
> for (auto x : xs) {
> m = f(m, x);
> }
> return m;
> }

But that's not my reduce_using.

> auto list_max(const auto & xs) {
> return reduce_using(
> [](auto a, auto b) { return (a > b) ? a : b; },
> xs);
> }

try the sum example with [](auto a, auto b) { return a + b; } and you'll
see.

> A slightly nicer (IMHO) functional programming style would have :
>
> list_max = reduce_using(max)

Of course. Indeed I wrote that (except without the ()s as it would be
in Haskell) but then thought I don't want people being puzzled by the
style.

--
Ben.

On 02/03/2022 22:04, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 02/03/2022 20:00, Bart wrote:

>>> It's an idea that sounds good on paper, but look at how C++ does it for
>>> example, where I believe they are implemented via templates. Need I say
>>> more? But then C++ always seems to make a dog's dinner out of any feature.
>>
>> auto list_max(const auto& xs)
>> {
>> auto m = xs[0];
>> for (auto x : xs) {
>> m = (m > x) ? m : x;
>> }
>> return m;
>> }
>>
>> Yes, that's clearly a dog's dinner.
>
> Not everyone will be 100% happy with it. What if the xs are huge
> objects -- are they being copied and will that all that be optimised
> away? (I think I know the answers -- those are rhetorical questions.)

xs is passed by reference; why should there be copying? The result will
be one of the elements.

If you mean the elements themselves might be large (eg. strings), then
it's something that the caller ought to aware of and do something about.

But it is easy to tweak, eg. return an index to the largest element instead.

>> auto reduce_using(auto f, auto & xs) {
>> auto m = xs[0];
>> for (auto x : xs) {
>> m = f(m, x);
>> }
>> return m;
>> }
>
> But that's not my reduce_using.

You mean because it first applies f between xs[0] and xs[0] instead of
x[0] and x[1]? (Also the behaviour for an empty xs is not clear). That's
likely just an oversight.

The examples were clearly mainly for my benefit in showing that C++ is
not that bad after all.

My quibble would be that this requires a function to be passed, but your
example (and mine) could pass operators too.

On Wednesday, 2 March 2022 at 23:23:46 UTC, Bart wrote:
> On 02/03/2022 22:04, Ben Bacarisse wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >> On 02/03/2022 20:00, Bart wrote:
>
> >>> It's an idea that sounds good on paper, but look at how C++ does it for
> >>> example, where I believe they are implemented via templates. Need I say
> >>> more? But then C++ always seems to make a dog's dinner out of any feature.
> >>
> >> auto list_max(const auto& xs)
> >> {
> >> auto m = xs[0];
> >> for (auto x : xs) {
> >> m = (m > x) ? m : x;
> >> }
> >> return m;
> >> }
> >>
> >> Yes, that's clearly a dog's dinner.
> >
> > Not everyone will be 100% happy with it. What if the xs are huge
> > objects -- are they being copied and will that all that be optimised
> > away? (I think I know the answers -- those are rhetorical questions.)
> xs is passed by reference; why should there be copying? The result will
> be one of the elements.
>
> If you mean the elements themselves might be large (eg. strings), then
> it's something that the caller ought to aware of and do something about.
>
> But it is easy to tweak, eg. return an index to the largest element instead.
> >> auto reduce_using(auto f, auto & xs) {
> >> auto m = xs[0];
> >> for (auto x : xs) {
> >> m = f(m, x);
> >> }
> >> return m;
> >> }
> >
> > But that's not my reduce_using.
> You mean because it first applies f between xs[0] and xs[0] instead of
> x[0] and x[1]? (Also the behaviour for an empty xs is not clear). That's
> likely just an oversight.
>
Not so much an oversight, as a weakness of the for (variable : container) syntax.
Whilst you usually need to iterate over a collection of objects, applying the
same operation to each one, the exceptions are not all that uncommon. In this
case the first element needs to be special-cased. That's very easy with counter-
based C-style for loops.

Bart <bc@freeuk.com> writes:

> On 02/03/2022 22:04, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 02/03/2022 20:00, Bart wrote:
>
>>>> It's an idea that sounds good on paper, but look at how C++ does it for
>>>> example, where I believe they are implemented via templates. Need I say
>>>> more? But then C++ always seems to make a dog's dinner out of any feature.
>>>
>>> auto list_max(const auto& xs)
>>> {
>>> auto m = xs[0];
>>> for (auto x : xs) {
>>> m = (m > x) ? m : x;
>>> }
>>> return m;
>>> }
>>>
>>> Yes, that's clearly a dog's dinner.
>
>> Not everyone will be 100% happy with it. What if the xs are huge
>> objects -- are they being copied and will that all that be optimised
>> away? (I think I know the answers -- those are rhetorical questions.)
>
> xs is passed by reference; why should there be copying? The result
> will be one of the elements.
>
> If you mean the elements themselves might be large (eg. strings), then
> it's something that the caller ought to aware of and do something
> about.

Finding and returning the maximum element in a collection only
/requires/ one element be copied -- the one being returned. This code
copies lots of elements about.

> But it is easy to tweak, eg. return an index to the largest element
> instead.

By the code does not assume that there is an index. The tweak is to use
references (or pointers) in the code and only copy one object on return.

>>> auto reduce_using(auto f, auto & xs) {
>>> auto m = xs[0];
>>> for (auto x : xs) {
>>> m = f(m, x);
>>> }
>>> return m;
>>> }
>>
>> But that's not my reduce_using.
>
> You mean because it first applies f between xs[0] and xs[0] instead of
> x[0] and x[1]? (Also the behaviour for an empty xs is not
> clear). That's likely just an oversight.

Yes, I know it's an oversight and in some way it's unfair to point it
out since David is coding this "on the fly", but it sort of matters
because it means you can't write it as simple as he is implying.

> The examples were clearly mainly for my benefit in showing that C++ is
> not that bad after all.

Yes, and they do that. I was nit-picking.

By the way, among the things that all modern language designs should
consider are type deduction (C++'s auto) and pattern matching. The
latter could handle both omitting the extra call and signalling when the
iterable is too short:

auto reduce_using(auto f, auto &xs) {
auto [m, rest] = xs; // raises an exception if xs.size() < 1
for (auto &x : rest)
m = f(m, x);
return m;
}

There is a proposal for pattern matching in C++ (using a new keyword
"inspect"), but I don't think it handles iterables.

--
Ben.

On Thursday, 3 March 2022 at 00:07:33 UTC, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 02/03/2022 22:04, Ben Bacarisse wrote:
> >> David Brown <david...@hesbynett.no> writes:
> >>
> >>> On 02/03/2022 20:00, Bart wrote:
> >
> >>>> It's an idea that sounds good on paper, but look at how C++ does it for
> >>>> example, where I believe they are implemented via templates. Need I say
> >>>> more? But then C++ always seems to make a dog's dinner out of any feature.
> >>>
> >>> auto list_max(const auto& xs)
> >>> {
> >>> auto m = xs[0];
> >>> for (auto x : xs) {
> >>> m = (m > x) ? m : x;
> >>> }
> >>> return m;
> >>> }
> >>>
> >>> Yes, that's clearly a dog's dinner.
> >
> >> Not everyone will be 100% happy with it. What if the xs are huge
> >> objects -- are they being copied and will that all that be optimised
> >> away? (I think I know the answers -- those are rhetorical questions.)
> >
> > xs is passed by reference; why should there be copying? The result
> > will be one of the elements.
> >
> > If you mean the elements themselves might be large (eg. strings), then
> > it's something that the caller ought to aware of and do something
> > about.
> Finding and returning the maximum element in a collection only
> /requires/ one element be copied -- the one being returned. This code
> copies lots of elements about.
> > But it is easy to tweak, eg. return an index to the largest element
> > instead.
> By the code does not assume that there is an index. The tweak is to use
> references (or pointers) in the code and only copy one object on return.
> >>> auto reduce_using(auto f, auto & xs) {
> >>> auto m = xs[0];
> >>> for (auto x : xs) {
> >>> m = f(m, x);
> >>> }
> >>> return m;
> >>> }
> >>
> >> But that's not my reduce_using.
> >
> > You mean because it first applies f between xs[0] and xs[0] instead of
> > x[0] and x[1]? (Also the behaviour for an empty xs is not
> > clear). That's likely just an oversight.
> Yes, I know it's an oversight and in some way it's unfair to point it
> out since David is coding this "on the fly", but it sort of matters
> because it means you can't write it as simple as he is implying.
> > The examples were clearly mainly for my benefit in showing that C++ is
> > not that bad after all.
> Yes, and they do that. I was nit-picking.
>
> By the way, among the things that all modern language designs should
> consider are type deduction (C++'s auto) and pattern matching. The
> latter could handle both omitting the extra call and signalling when the
> iterable is too short:
>
> auto reduce_using(auto f, auto &xs) {
> auto [m, rest] = xs; // raises an exception if xs.size() < 1
> for (auto &x : rest)
> m = f(m, x);
> return m;
> }
> There is a proposal for pattern matching in C++ (using a new keyword
> "inspect"), but I don't think it handles iterables.
>
Here's the C version.
int reduce_using(void *x, int N, size_t elsize, void (*op)(void *context, void *dest, const void *a, const void *b), void *context)
{ void *temp = malloc(elsize);
int i;

if (!temp)
return -1;
for (i = 1; i < N, i++)
{
(*op)(context, temp, x,((unsigned char *) x) + i * elsize);
memcpy(x, temp, elsize);
}

free(temp);
return 0;
}

C's not really designed to do this so it's a bit clumsy. But it doesn't require knowing
that
auto [a b] = x
puts the first element of x in a, and the rest of the list in b. I't's all explicit.

On 3/2/2022 1:19 PM, Bart wrote:
> On 02/03/2022 18:06, rthiebaud wrote:
>>>>>>> standard.
>>>>>>>
>>> * Whole-program compilers
>>> * 64-bit everything (C is still stuck on 32-bits)
>>> * Super-fast compilers ...
>>   Who says
>> C is stuck is 32 bits?
>
> It just is. While versions with 64-bit ints might be knocking about,
> generally they have to be compatible with what C already does on a given
> platform. And that usually means int = 32 bits.
>
> So, while people can choose to use long long int or int64_t, they have
> to explicity state that everywhere, because:
>
>   12345          is int32
>   'A'            is int32
>   short a,b,c;
>      a*b*c       is int32 (so could overflow)
>   %d             means int32 format
>   sprintf        returns int32
>   f(){}          defaults to int32 return type
>   int64_t a,b;
>   a && b         is int32
>   !a             is int32
>   enum E {a=5000000000};
>   enum E xx;     is int32 (int64 on some compilers with extensions)
>
> etc

Well, that is a bummer. That means that I will have to explicitly type
everything int64 when we move to Win64.

I already knew that I was going to have to change all the integer types
in my Fortran code integer*8 but I expected 64 bit C to treat int at 64 bit.

Lynn

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Thursday, 3 March 2022 at 00:07:33 UTC, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>> > On 02/03/2022 22:04, Ben Bacarisse wrote:
>> >> David Brown <david...@hesbynett.no> writes:
>> >>
>> >>> On 02/03/2022 20:00, Bart wrote:
>> >
>> >>>> It's an idea that sounds good on paper, but look at how C++ does it for
>> >>>> example, where I believe they are implemented via templates. Need I say
>> >>>> more? But then C++ always seems to make a dog's dinner out of any feature.
>> >>>
>> >>> auto list_max(const auto& xs)
>> >>> {
>> >>> auto m = xs[0];
>> >>> for (auto x : xs) {
>> >>> m = (m > x) ? m : x;
>> >>> }
>> >>> return m;
>> >>> }
>> >>>
>> >>> Yes, that's clearly a dog's dinner.
>> >
>> >> Not everyone will be 100% happy with it. What if the xs are huge
>> >> objects -- are they being copied and will that all that be optimised
>> >> away? (I think I know the answers -- those are rhetorical questions.)
>> >
>> > xs is passed by reference; why should there be copying? The result
>> > will be one of the elements.
>> >
>> > If you mean the elements themselves might be large (eg. strings), then
>> > it's something that the caller ought to aware of and do something
>> > about.
>> Finding and returning the maximum element in a collection only
>> /requires/ one element be copied -- the one being returned. This code
>> copies lots of elements about.
>> > But it is easy to tweak, eg. return an index to the largest element
>> > instead.
>> By the code does not assume that there is an index. The tweak is to use
>> references (or pointers) in the code and only copy one object on return.
>> >>> auto reduce_using(auto f, auto & xs) {
>> >>> auto m = xs[0];
>> >>> for (auto x : xs) {
>> >>> m = f(m, x);
>> >>> }
>> >>> return m;
>> >>> }
>> >>
>> >> But that's not my reduce_using.
>> >
>> > You mean because it first applies f between xs[0] and xs[0] instead of
>> > x[0] and x[1]? (Also the behaviour for an empty xs is not
>> > clear). That's likely just an oversight.
>> Yes, I know it's an oversight and in some way it's unfair to point it
>> out since David is coding this "on the fly", but it sort of matters
>> because it means you can't write it as simple as he is implying.
>> > The examples were clearly mainly for my benefit in showing that C++ is
>> > not that bad after all.
>> Yes, and they do that. I was nit-picking.
>>
>> By the way, among the things that all modern language designs should
>> consider are type deduction (C++'s auto) and pattern matching. The
>> latter could handle both omitting the extra call and signalling when the
>> iterable is too short:
>>
>> auto reduce_using(auto f, auto &xs) {
>> auto [m, rest] = xs; // raises an exception if xs.size() < 1
>> for (auto &x : rest)
>> m = f(m, x);
>> return m;
>> }

I did not write this! Your posting has messed up my indentation and
spacing.

>> There is a proposal for pattern matching in C++ (using a new keyword
>> "inspect"), but I don't think it handles iterables.
>>
> Here's the C version.
>
> int reduce_using(void *x, int N, size_t elsize, void (*op)(void *context, void *dest, const void *a, const void *b), void *context)
> {
> void *temp = malloc(elsize);
> int i;
>
> if (!temp)
> return -1;
> for (i = 1; i < N, i++)
> {
> (*op)(context, temp, x,((unsigned char *) x) + i * elsize);
> memcpy(x, temp, elsize);
> }
>
> free(temp);
> return 0;
> }

Did you intend the interface to overwrite the first element of the input
array? That's not all the same kind of function!

And it does not (indeed cannot) return the calculated result, nor does
it work for anything but arrays, whereas the C++ version (once
corrected) will work for maps and set and linked lists and so on.

Also, I think you have slightly over complicated it. I'd write:

void reduce_using(void *array, size_t esize, size_t nelem, void *dest,
void (*op)(void *dest, const void *a, const void *b))
{ memmove(dest, array, esize);
char (*elems)[esize] = array;
for (size_t i = 1; i < nelem; i++)
op(dest, dest, elems[i]);
}

All the differences were deliberate, though some are just a matter of
preference. I've:

* made the order and types of the size and count arguments the same as
for fread;

* removed the context pointer as this should really only be used for
pure functions;

* simplified the address calculation using a variably modified type (not
a VLA);

* required the caller provide a separate destination (though they could
emulate your interface by pointing to the first array element).

> C's not really designed to do this so it's a bit clumsy. But it
> doesn't require knowing that
> auto [a b] = x
> puts the first element of x in a, and the rest of the list in b. I't's
> all explicit.

No, but it requires knowing lots of other things. I don't like these
"feature X is mysterious" augments as they just depend on what you
already know.

--
Ben.

On 03/03/2022 12:32, Lynn McGuire wrote:
> On 3/2/2022 1:19 PM, Bart wrote:
>> On 02/03/2022 18:06, rthiebaud wrote:
>>>>>>>> standard.
>>>>>>>>
>>>> * Whole-program compilers
>>>> * 64-bit everything (C is still stuck on 32-bits)
>>>> * Super-fast compilers ...
>>>   Who says
>>> C is stuck is 32 bits?
>>
>> It just is. While versions with 64-bit ints might be knocking about,
>> generally they have to be compatible with what C already does on a
>> given platform. And that usually means int = 32 bits.
>>
>> So, while people can choose to use long long int or int64_t, they have
>> to explicity state that everywhere, because:
>>
>>    12345          is int32
>>    'A'            is int32
>>    short a,b,c;
>>       a*b*c       is int32 (so could overflow)
>>    %d             means int32 format
>>    sprintf        returns int32
>>    f(){}          defaults to int32 return type
>>    int64_t a,b;
>>    a && b         is int32
>>    !a             is int32
>>    enum E {a=5000000000};
>>    enum E xx;     is int32 (int64 on some compilers with extensions)
>>
>> etc
>
> Well, that is a bummer.  That means that I will have to explicitly type
> everything int64 when we move to Win64.
>
> I already knew that I was going to have to change all the integer types
> in my Fortran code integer*8 but I expected 64 bit C to treat int at 64
> bit.

On 64-bit Linux, the default gcc instance builds 64-bit binaries, using
the I32LP64 model.

The Alpha was nice, it's default was ILP64.

Winderrs is worse, it use IL32P64, I'll leave dealing with the
assumptions C programmers have made over the decades to your imagination.

I've been using my own set of typedefs to control things since the early
1990's, and being hard on myself and occasional minions about not using
"int" anywhere. Edit one header file and everything is as big/small as
you need/want. :-)

Cheers,
Gary B-)

On Thursday, 3 March 2022 at 01:59:40 UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Thursday, 3 March 2022 at 00:07:33 UTC, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >> > On 02/03/2022 22:04, Ben Bacarisse wrote:
> >> >> David Brown <david...@hesbynett.no> writes:
> >> >>
> >> >>> On 02/03/2022 20:00, Bart wrote:
> >> >
> >> >>>> It's an idea that sounds good on paper, but look at how C++ does it for
> >> >>>> example, where I believe they are implemented via templates. Need I say
> >> >>>> more? But then C++ always seems to make a dog's dinner out of any feature.
> >> >>>
> >> >>> auto list_max(const auto& xs)
> >> >>> {
> >> >>> auto m = xs[0];
> >> >>> for (auto x : xs) {
> >> >>> m = (m > x) ? m : x;
> >> >>> }
> >> >>> return m;
> >> >>> }
> >> >>>
> >> >>> Yes, that's clearly a dog's dinner.
> >> >
> >> >> Not everyone will be 100% happy with it. What if the xs are huge
> >> >> objects -- are they being copied and will that all that be optimised
> >> >> away? (I think I know the answers -- those are rhetorical questions.)
> >> >
> >> > xs is passed by reference; why should there be copying? The result
> >> > will be one of the elements.
> >> >
> >> > If you mean the elements themselves might be large (eg. strings), then
> >> > it's something that the caller ought to aware of and do something
> >> > about.
> >> Finding and returning the maximum element in a collection only
> >> /requires/ one element be copied -- the one being returned. This code
> >> copies lots of elements about.
> >> > But it is easy to tweak, eg. return an index to the largest element
> >> > instead.
> >> By the code does not assume that there is an index. The tweak is to use
> >> references (or pointers) in the code and only copy one object on return.
> >> >>> auto reduce_using(auto f, auto & xs) {
> >> >>> auto m = xs[0];
> >> >>> for (auto x : xs) {
> >> >>> m = f(m, x);
> >> >>> }
> >> >>> return m;
> >> >>> }
> >> >>
> >> >> But that's not my reduce_using.
> >> >
> >> > You mean because it first applies f between xs[0] and xs[0] instead of
> >> > x[0] and x[1]? (Also the behaviour for an empty xs is not
> >> > clear). That's likely just an oversight.
> >> Yes, I know it's an oversight and in some way it's unfair to point it
> >> out since David is coding this "on the fly", but it sort of matters
> >> because it means you can't write it as simple as he is implying.
> >> > The examples were clearly mainly for my benefit in showing that C++ is
> >> > not that bad after all.
> >> Yes, and they do that. I was nit-picking.
> >>
> >> By the way, among the things that all modern language designs should
> >> consider are type deduction (C++'s auto) and pattern matching. The
> >> latter could handle both omitting the extra call and signalling when the
> >> iterable is too short:
> >>
> >> auto reduce_using(auto f, auto &xs) {
> >> auto [m, rest] = xs; // raises an exception if xs.size() < 1
> >> for (auto &x : rest)
> >> m = f(m, x);
> >> return m;
> >> }
> I did not write this! Your posting has messed up my indentation and
> spacing.
> >> There is a proposal for pattern matching in C++ (using a new keyword
> >> "inspect"), but I don't think it handles iterables.
> >>
> > Here's the C version.
> >
> > int reduce_using(void *x, int N, size_t elsize, void (*op)(void *context, void *dest, const void *a, const void *b), void *context)
> > {
> > void *temp = malloc(elsize);
> > int i;
> >
> > if (!temp)
> > return -1;
> > for (i = 1; i < N, i++)
> > {
> > (*op)(context, temp, x,((unsigned char *) x) + i * elsize);
> > memcpy(x, temp, elsize);
> > }
> >
> > free(temp);
> > return 0;
> > }
> Did you intend the interface to overwrite the first element of the input
> array? That's not all the same kind of function!
>
Yes. But that was probably a mistake.
>
> And it does not (indeed cannot) return the calculated result, nor does
> it work for anything but arrays, whereas the C++ version (once
> corrected) will work for maps and set and linked lists and so on.
>
But arrays are by far and away the most common data structure for
things thta reduce makes sense for.
> Also, I think you have slightly over complicated it. I'd write:
>
> void reduce_using(void *array, size_t esize, size_t nelem, void *dest,
> void (*op)(void *dest, const void *a, const void *b))
> {
> memmove(dest, array, esize);
> char (*elems)[esize] = array;
> for (size_t i = 1; i < nelem; i++)
> op(dest, dest, elems[i]);
> }
>
> All the differences were deliberate, though some are just a matter of
> preference. I've:
>
> * made the order and types of the size and count arguments the same as
> for fread;
>
I was using qsort as the pattern.
>
> * removed the context pointer as this should really only be used for
> pure functions;
>
It probably will be null most of the time here, but it means that globals
are never necessary.
> * simplified the address calculation using a variably modified type (not
> a VLA);
>
Oh, that's nice. But agian, it's confusing syntax. OTOH a cast to unsigned char *
is also confusing.
> * required the caller provide a separate destination (though they could
> emulate your interface by pointing to the first array element).
>
I was thinkng that if you reduce an array, you turn it into an array of one element.
However you can't alias the pointers to the comparison function without
documenting it. Otherwise someone could write to a dest member, then
access it through the const * to a.
>
> > C's not really designed to do this so it's a bit clumsy. But it
> > doesn't require knowing that
> > auto [a b] = x
> > puts the first element of x in a, and the rest of the list in b. I't's
> > all explicit.
> No, but it requires knowing lots of other things. I don't like these
> "feature X is mysterious" augments as they just depend on what you
> already know.
>
Most people who program C know an imperative programming language.
But their eyes glaze over when presented with lots of ad-hoc syntax
which deals mainly with the internals of the programming language itself
rather than the data and algorithms the program is expressing.

That's a huge advantage of C. Except for pointers, if you know another language,
you know enough to be a sucessful C programmer without learning much
at all.

Am 03.03.2022 um 02:32 schrieb Lynn McGuire:
> On 3/2/2022 1:19 PM, Bart wrote:
>> On 02/03/2022 18:06, rthiebaud wrote:
>>>>>>>> standard.
>>>>>>>>
>>>> * Whole-program compilers
>>>> * 64-bit everything (C is still stuck on 32-bits)
>>>> * Super-fast compilers ...
>>>   Who says
>>> C is stuck is 32 bits?
>>
>> It just is. While versions with 64-bit ints might be knocking about,
>> generally they have to be compatible with what C already does on a
>> given platform. And that usually means int = 32 bits.
>>
>> So, while people can choose to use long long int or int64_t, they have
>> to explicity state that everywhere, because:
>>
>>    12345          is int32
>>    'A'            is int32
>>    short a,b,c;
>>       a*b*c       is int32 (so could overflow)
>>    %d             means int32 format
>>    sprintf        returns int32
>>    f(){}          defaults to int32 return type
>>    int64_t a,b;
>>    a && b         is int32
>>    !a             is int32
>>    enum E {a=5000000000};
>>    enum E xx;     is int32 (int64 on some compilers with extensions)
>>
>> etc
>
> Well, that is a bummer.  That means that I will have to explicitly type
> everything int64 when we move to Win64.

If you need a scalar type that always matches the with of
the general purpose integer-registers use size_t or ptrdiff_t.

On 3/2/2022 8:19 PM, Bart wrote:
> On 02/03/2022 18:06, rthiebaud wrote:
>>>>>>> standard.
>>>>>>>
>>> * Whole-program compilers
>>> * 64-bit everything (C is still stuck on 32-bits)
>>> * Super-fast compilers ...
>>   Who says
>> C is stuck is 32 bits?
>
> It just is. While versions with 64-bit ints might be knocking about,
> generally they have to be compatible with what C already does on a given
> platform. And that usually means int = 32 bits.
>
> So, while people can choose to use long long int or int64_t, they have
> to explicity state that everywhere, because:
>
>   12345          is int32
>   'A'            is int32
>   short a,b,c;
>      a*b*c       is int32 (so could overflow)
>   %d             means int32 format
>   sprintf        returns int32
>   f(){}          defaults to int32 return type
>   int64_t a,b;
>   a && b         is int32
>   !a             is int32
>   enum E {a=5000000000};
>   enum E xx;     is int32 (int64 on some compilers with extensions)
>
> etc

Are you seriously suggesting that the default size of int should be 64
bits everywhere?
Even for a general purpose counter from 1 to 10?

Am 03.03.2022 um 15:09 schrieb Manfred:
> On 3/2/2022 8:19 PM, Bart wrote:
>> On 02/03/2022 18:06, rthiebaud wrote:
>>>>>>>> standard.
>>>>>>>>
>>>> * Whole-program compilers
>>>> * 64-bit everything (C is still stuck on 32-bits)
>>>> * Super-fast compilers ...
>>>   Who says
>>> C is stuck is 32 bits?
>>
>> It just is. While versions with 64-bit ints might be knocking about,
>> generally they have to be compatible with what C already does on a
>> given platform. And that usually means int = 32 bits.
>>
>> So, while people can choose to use long long int or int64_t, they have
>> to explicity state that everywhere, because:
>>
>>    12345          is int32
>>    'A'            is int32
>>    short a,b,c;
>>       a*b*c       is int32 (so could overflow)
>>    %d             means int32 format
>>    sprintf        returns int32
>>    f(){}          defaults to int32 return type
>>    int64_t a,b;
>>    a && b         is int32
>>    !a             is int32
>>    enum E {a=5000000000};
>>    enum E xx;     is int32 (int64 on some compilers with extensions)
>>
>> etc
>
> Are you seriously suggesting that the default size of int should be 64
> bits everywhere?
> Even for a general purpose counter from 1 to 10?

Even if an int is only 32 bit that's too much. ^^