On 03/03/2022 14:09, Manfred wrote:
> 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?

As BM said, even int32 is overkill in that case.

But what exactly is the problem? Most desktop PCs use 64-bit processors;
I'd guess most phones and other consumer kit does as well.

They will already have 64-bit registers, 64-bit stack slots, 64-bit
addresses and will be using 64-bit floats.

There's little advantage in having standalone int variables, parameters
and return types being 32 bits. (For parameters, each will use a 64-bit
register or stack slot anyway, and the return value will be in a 64-bit
register.) Pointers of course will already be 64 bits.

Sure, for arrays and structs, then you can choose narrower types if you
want, since they can otherwise use twice as much memory, but not as a
default type.

You want to be able to write 1<<40 without remembering to do 1LL<<40,
and to more or less forget about integer overflows in calculations,
since int64 has a numeric range 4 billion times wider than int32.

Int64 also covers the ranges of all u8 to u32 types.

You can also write %d as a format, without wondering whether it's %ld or
%lld or PRId64 or whatever.

(I've developed and used languages with a 64-bit type for a decade, and
it is a joy.)

On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
> On 3/2/2022 8:19 PM, Bart wrote:
>
> 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?
>
The vast majority of integers are small. But there's a lot to be said for
having one integer type which is used everywhere there isn't a strong
case against, which can count any collection of objects in the computer's
memory, and which is called "int".

On Thursday, 3 March 2022 at 14:49:14 UTC, Bart wrote:
> On 03/03/2022 14:09, Manfred wrote:
> > 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?
> As BM said, even int32 is overkill in that case.
>
> But what exactly is the problem? Most desktop PCs use 64-bit processors;
> I'd guess most phones and other consumer kit does as well.
>
> They will already have 64-bit registers, 64-bit stack slots, 64-bit
> addresses and will be using 64-bit floats.
>
> There's little advantage in having standalone int variables, parameters
> and return types being 32 bits. (For parameters, each will use a 64-bit
> register or stack slot anyway, and the return value will be in a 64-bit
> register.) Pointers of course will already be 64 bits.
>
> Sure, for arrays and structs, then you can choose narrower types if you
> want, since they can otherwise use twice as much memory, but not as a
> default type.
>
It's not the memory take, at least on a modern big system. It's the cache
usage. The processor spends a significant amount of its time refilling
the cache when it misses.

On 3/3/2022 4:19 PM, Malcolm McLean wrote:
> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>> On 3/2/2022 8:19 PM, Bart wrote:
>>
>> 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?
>>
> The vast majority of integers are small.

Yes, and there's an advantage in keeping their size somewhat limited,
even on 64 bit processors. I'd say that should be clear for anyone.

But there's a lot to be said for
> having one integer type which is used everywhere there isn't a strong
> case against, which can count any collection of objects in the computer's
> memory, and which is called "int".

Of course there can be a lot to be said, the definition of "int" is
(intentionally) left largely unspecified, and in every project lack of
specification leads to lots of discussion.

My point is that the issue should be looked at the other way around:

/If/ you have strong requirements on a variable, you choose its size
accordingly, and C gives you all the means to do that - expecially since
<stdint.h>

/If/ all you need is a general purpose integer, and you know its range
is limited, then you may delegate the final choice to the
implementation, which knows better how to optimize its performance -
that's what "int" is for.

In other words, if you have a sequence of readings from a sensor of
arbitrary length, and you index them with an "int", it's you who are
Doing it Wrong™.

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

> On Thursday, 3 March 2022 at 01:59:40 UTC, Ben Bacarisse wrote:

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

(Except for the types!) I had not noticed they went the other way in
qsort. How annoying that there is no uniform convention.

I agree, though, that echoing qsort is better here since it is more
directly comparable.

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

I was making a stronger point: I would want to discourage use of this
function with anything but a pure operator. You can't enforce that, but
not provided in a context pointer is a big nudge.

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

It's confusing because it's not common, and that's a self-reinforcing
loop.

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

Are you putting pattern matching (sometimes called destructuring) into
that category? I wouldn't.

--
Ben.

On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:

> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>> On 3/2/2022 8:19 PM, Bart wrote:
>>
>> 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?
>>
> The vast majority of integers are small. But there's a lot to be said for
> having one integer type which is used everywhere there isn't a strong
> case against, which can count any collection of objects in the computer's
> memory, and which is called "int".

I think that your requirements are already met, with the exception that
the integer type is called
size_t
instead of
int

--
Lew Pitcher
"In Skills, We Trust"

Am 03.03.2022 um 17:06 schrieb Lew Pitcher:
> On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
>
>> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>>> On 3/2/2022 8:19 PM, Bart wrote:
>>>
>>> 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?
>>>
>> The vast majority of integers are small. But there's a lot to be said for
>> having one integer type which is used everywhere there isn't a strong
>> case against, which can count any collection of objects in the computer's
>> memory, and which is called "int".
>
> I think that your requirements are already met, with the exception that
> the integer type is called
> size_t
> instead of
> int

ptrdiff_t is the int-counterpart that fits in a general purpose
register. size_t is unsigned.

On 03/03/2022 15:32, Malcolm McLean wrote:
> On Thursday, 3 March 2022 at 14:49:14 UTC, Bart wrote:
>> On 03/03/2022 14:09, Manfred wrote:
>>> 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?
>> As BM said, even int32 is overkill in that case.
>>
>> But what exactly is the problem? Most desktop PCs use 64-bit processors;
>> I'd guess most phones and other consumer kit does as well.
>>
>> They will already have 64-bit registers, 64-bit stack slots, 64-bit
>> addresses and will be using 64-bit floats.
>>
>> There's little advantage in having standalone int variables, parameters
>> and return types being 32 bits. (For parameters, each will use a 64-bit
>> register or stack slot anyway, and the return value will be in a 64-bit
>> register.) Pointers of course will already be 64 bits.
>>
>> Sure, for arrays and structs, then you can choose narrower types if you
>> want, since they can otherwise use twice as much memory, but not as a
>> default type.
>>
> It's not the memory take, at least on a modern big system. It's the cache
> usage. The processor spends a significant amount of its time refilling
> the cache when it misses.

As I said elsewhere, where there is extensive memory usage such as in
arrays and arrays of structs, then you choose those elements accordingly.

But you will be already doing that when choosing 8-bit and 16-bit ints
over plain int, if int32 is not needed.

With local variables, generally they will be concentrated within a stack
region a few KB in size. Many will reside in registers anyway.

What might take extra time with 64 bits are ops like * and /; then you
might specifically choose an int32 type.

With an int64 type, you wouldn't really need separate types like size_t
(unless you want it as unsigned because you machine can actually address
2**64 bytes), off_t, intptr_t and so on. It can all become a lot tidier.

On 03/03/2022 16:06, Lew Pitcher wrote:
> On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
>
>> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>>> On 3/2/2022 8:19 PM, Bart wrote:
>>>
>>> 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?
>>>
>> The vast majority of integers are small. But there's a lot to be said for
>> having one integer type which is used everywhere there isn't a strong
>> case against, which can count any collection of objects in the computer's
>> memory, and which is called "int".
>
> I think that your requirements are already met, with the exception that
> the integer type is called
> size_t
> instead of
> int

This about the default int type, not user code choosing to use size_t.

Using size_t or uint64_t or int64_t or long long int for some explicit
types won't affect everything that defaults to 'int', or that has an int
result like !A.

Neither can it affect APIs of external libraries that use 'int'. Even if
you somehow, through macros or typedefs, manage to map 'int' to
'int64_t', when processing headers for those APIs, now the compiler will
incorrectly think they are using int64 types when they are actually int32.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 03.03.2022 um 17:06 schrieb Lew Pitcher:
>> On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
>>
>>> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>>>> On 3/2/2022 8:19 PM, Bart wrote:
>>>>
>>>> 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?
>>>>
>>> The vast majority of integers are small. But there's a lot to be said for
>>> having one integer type which is used everywhere there isn't a strong
>>> case against, which can count any collection of objects in the computer's
>>> memory, and which is called "int".
>>
>> I think that your requirements are already met, with the exception that
>> the integer type is called
>> size_t
>> instead of
>> int
>
>ptrdiff_t is the int-counterpart that fits in a general purpose
>register. size_t is unsigned.

Of course, one can alway use ssize_t.

On 02/03/2022 23:04, Ben Bacarisse wrote:
> 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.

Yes. I also had this version :

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

but I thought I'd keep it a little simpler for the demonstration. (It
also doesn't handle empty containers as it stands.)

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

scott@slp53.sl.home (Scott Lurndal) writes:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>Am 03.03.2022 um 17:06 schrieb Lew Pitcher:
>>> On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
>>>
>>>> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>>>>> On 3/2/2022 8:19 PM, Bart wrote:
>>>>>
>>>>> 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?
>>>>>
>>>> The vast majority of integers are small. But there's a lot to be said for
>>>> having one integer type which is used everywhere there isn't a strong
>>>> case against, which can count any collection of objects in the computer's
>>>> memory, and which is called "int".
>>>
>>> I think that your requirements are already met, with the exception that
>>> the integer type is called
>>> size_t
>>> instead of
>>> int
>>
>>ptrdiff_t is the int-counterpart that fits in a general purpose
>>register. size_t is unsigned.
>
> Of course, one can alway use ssize_t.

No, one can't always use ssize_t. It's defined by POSIX, not by ISO C
(even in the latest C23 draft), and POSIX doesn't guarantee that it's
the signed type corresponding to size_t.

ptrdiff_t is often the same size as size_t, but that's not guaranteed.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 03/03/2022 01:06, Ben Bacarisse wrote:
> 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.

The nit-picks are all valid. And that is a reason why it is often
better to use the standard library routines instead, such as
implementing reduce_using as something like :

constexpr auto reduce_using(auto f, auto &xs) {
auto i = std::begin(xs);
auto init = *i++;
return std::accumulate(i, std::end(xs), init);
}

(There isn't really anything it could reasonably return for an empty
container.)

But as you say, the main point was to show that templated code isn't
necessarily more difficult to write or understand than "normal" code.
(Sometimes templates can be complex, however - sometimes of necessity,
sometimes unnecessarily. I'll leave it to Bonita to provide examples :-) )

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

I believe there have been many proposals for adding pattern matching to
C++ (and I hope we get one eventually). But I don't remember seeing any
that have the lovely "head ++ tail" pattern matching so standard in
functional programming.

On Thursday, 3 March 2022 at 19:47:11 UTC, David Brown wrote:
> On 03/03/2022 01:06, 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.
> The nit-picks are all valid. And that is a reason why it is often
> better to use the standard library routines instead, such as
> implementing reduce_using as something like :
>
> constexpr auto reduce_using(auto f, auto &xs) {
> auto i = std::begin(xs);
> auto init = *i++;
> return std::accumulate(i, std::end(xs), init);
> }
>
I don't see the call to f() anywhere in this code. Presumably
an error. Also, "auto" helps the compiler out, but it's not terribly
useful to the maintaining programmer. f has to be a callable
function that takes two objects of the type contained in xs
and returns an object of the same same. xs has to be a container
with an stl-like iterator system defined, and needs to be filled with
at least one object of the type returned by f.

On 03/03/2022 20:58, Malcolm McLean wrote:
> On Thursday, 3 March 2022 at 19:47:11 UTC, David Brown wrote:
>> On 03/03/2022 01:06, 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.
>> The nit-picks are all valid. And that is a reason why it is often
>> better to use the standard library routines instead, such as
>> implementing reduce_using as something like :
>>
>> constexpr auto reduce_using(auto f, auto &xs) {
>> auto i = std::begin(xs);
>> auto init = *i++;
>> return std::accumulate(i, std::end(xs), init);
>> }
>>
> I don't see the call to f() anywhere in this code. Presumably
> an error.

Yes - the code was not tested at all (obviously).

return std::accumulate(i, std::end(xs), init, f);

> Also, "auto" helps the compiler out, but it's not terribly
> useful to the maintaining programmer. f has to be a callable
> function that takes two objects of the type contained in xs
> and returns an object of the same same. xs has to be a container
> with an stl-like iterator system defined, and needs to be filled with
> at least one object of the type returned by f.
>

Sure, "auto" can be replaced by a useful concept name.

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

> Yes. I also had this version :
>
> auto reduce_using(auto f, const auto & xs) {
> auto m = xs[0];
> for (auto x : xs | std::views::drop(1)) {
> m = f(m, x);
> }
> return m;
> }
>
> but I thought I'd keep it a little simpler for the demonstration. (It
> also doesn't handle empty containers as it stands.)

And then you are almost writing Haskell -- composing closures with an
overloaded | operator!

You could have compromised and done the drop directly:

for (auto x : std::ranges::drop_view(xs, 1)) ...

but I suppose everyone will have to get used to the x | view1 | view2
pattern soon enough.

--
Ben.

On 2/28/2022 9: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.

Moving Linux to Standard C11 has to involve a lot of porting over to the
std atomics and membars in C11.

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

> On 03/03/2022 01:06, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:

>>> 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.
>
> The nit-picks are all valid. And that is a reason why it is often
> better to use the standard library routines instead, such as
> implementing reduce_using as something like :
>
> constexpr auto reduce_using(auto f, auto &xs) {
> auto i = std::begin(xs);
> auto init = *i++;
> return std::accumulate(i, std::end(xs), init);
> }

(The f is missing as the last argument.)

I suspect this, including a drop(1), can be done with std::views since
they can combine with std::algorithms (but I'm guessing).

> I believe there have been many proposals for adding pattern matching to
> C++ (and I hope we get one eventually). But I don't remember seeing any
> that have the lovely "head ++ tail" pattern matching so standard in
> functional programming.

Extreme topic drift now, but it's usually head : tail. I've only seen
++ as a list append operator, and matching against that would force head
to be a list as well as tail (with undefined consequences).

--
Ben.

Am 03.03.2022 um 21:25 schrieb Chris M. Thomasson:
> On 2/28/2022 9: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.
>
> Moving Linux to Standard C11 has to involve a lot of porting over to the
> std atomics and membars in C11.

The code needs not to be portable beyond gcc and clang.

On 3/3/2022 12:37 PM, Bonita Montero wrote:
> Am 03.03.2022 um 21:25 schrieb Chris M. Thomasson:
>> On 2/28/2022 9: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.
>>
>> Moving Linux to Standard C11 has to involve a lot of porting over to
>> the std atomics and membars in C11.
>
> The code needs not to be portable beyond gcc and clang.

Well, I was thinking if they altered their existing atomics and membars
to 100% pure C11, that would be a shit load of work. I can do it, but it
would take a very long time.

On 03/03/2022 16:06, Lew Pitcher wrote:
> On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
>
>> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>>> On 3/2/2022 8:19 PM, Bart wrote:
>>>
>>> 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?
>>>
>> The vast majority of integers are small. But there's a lot to be said for
>> having one integer type which is used everywhere there isn't a strong
>> case against, which can count any collection of objects in the computer's
>> memory, and which is called "int".
>
> I think that your requirements are already met, with the exception that
> the integer type is called
> size_t
> instead of
> int
>
size_t makes sense. It's a platform sized value which is the largest
possible array index.

But int? What does it mean if the collection size is -1?

unsigned might be right. On some platforms, but not all the ones I've
used in the past.

int has always been at least 16 bits for me. 32 usually these days, but
I have used systems where it's 64.

And in the dim distant past when I wasn't writing C an integer was 24 or
64 bits on 2 different mainframes.

There's also no guarantee that the size of a pointer is the same as the
size of the array index... some architectures embed checks in the pointers.

Andy

On 01/03/2022 18:42, David Brown wrote:
> That does not contradict me in any way. Companies are looking for new
> people with C++ skills, because - as I said - the use of C++ in embedded
> systems is/increasing/. They don't need new C programmers, because
> they already have C programmers.

We're embedded systems. (though it seems odd to me to use that term for
something with a thousand times more memory than the mainframes I
started on...)

The OS layer is Linux, and it's in C. Including the libraries we get
from the chip manufacturers, and we often end up hacking them. We don't
often have to fiddle with Linux, but it's not that rare we're looking
into the code to see what went wrong...

The application we run on top is entirely C++.

At the skill levels we require I would be astounded to find anyone who
cannot use both languages at least to some degree.

That's skill BTW, not experience - we have an intern system where we
bring in undergraduates for their last summer. A lot of them get job offers.

Andy

On Thursday, 3 March 2022 at 21:36:09 UTC, Vir Campestris wrote:
> On 03/03/2022 16:06, Lew Pitcher wrote:
> > On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
> >
> >> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
> >>> On 3/2/2022 8:19 PM, Bart wrote:
> >>>
> >>> 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?
> >>>
> >> The vast majority of integers are small. But there's a lot to be said for
> >> having one integer type which is used everywhere there isn't a strong
> >> case against, which can count any collection of objects in the computer's
> >> memory, and which is called "int".
> >
> > I think that your requirements are already met, with the exception that
> > the integer type is called
> > size_t
> > instead of
> > int
> >
> size_t makes sense. It's a platform sized value which is the largest
> possible array index.
>
> But int? What does it mean if the collection size is -1?
>
void tail(double *x, size_t N)
{ size_t i;
for (i =0; i < N-1; i++)
x[i] = x[i+1];
}

void caller(void)
{ size_t N;
double * x = inputarrayfromuser(&N);
// throw away first value
tail(x, N);
}

On 03/03/2022 21:35, Vir Campestris wrote:
> On 03/03/2022 16:06, Lew Pitcher wrote:
>> On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
>>
>>> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>>>> On 3/2/2022 8:19 PM, Bart wrote:
>>>>
>>>> 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?
>>>>
>>> The vast majority of integers are small. But there's a lot to be said
>>> for
>>> having one integer type which is used everywhere there isn't a strong
>>> case against, which can count any collection of objects in the
>>> computer's
>>> memory, and which is called "int".
>>
>> I think that your requirements are already met, with the exception that
>> the integer type is called
>>    size_t
>> instead of
>>    int
>>
> size_t makes sense. It's a platform sized value which is the largest
> possible array index.
>
> But int? What does it mean if the collection size is -1?

What does it mean if the size is 2**64-1?

I have however used a length of -1 to indicate the length was unknown or
not set or not valid.

> unsigned might be right. On some platforms, but not all the ones I've
> used in the past.
>
> int has always been at least 16 bits for me. 32 usually these days, but
> I have used systems where it's 64.

It should be a 'don't care' width. But these days you need to care too
often whether a 32-bit width is sufficient. (Memory size calculations;
file/disk sizes; the number of people on the planet; type-punning
pointers or doubles. 64 bits is a no-brainer.)

> And in the dim distant past when I wasn't writing C an integer was 24 or
> 64 bits on 2 different mainframes.
>
> There's also no guarantee that the size of a pointer is the same as the
> size of the array index... some architectures embed checks in the pointers.

And a HLL can ensure that the programmer sees a model where they /are/
the same. That's why it's a HLL.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>Am 03.03.2022 um 17:06 schrieb Lew Pitcher:
>>>> On Thu, 03 Mar 2022 07:19:55 -0800, Malcolm McLean wrote:
>>>>
>>>>> On Thursday, 3 March 2022 at 14:10:06 UTC, Manfred wrote:
>>>>>> On 3/2/2022 8:19 PM, Bart wrote:
>>>>>>
>>>>>> 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?
>>>>>>
>>>>> The vast majority of integers are small. But there's a lot to be said for
>>>>> having one integer type which is used everywhere there isn't a strong
>>>>> case against, which can count any collection of objects in the computer's
>>>>> memory, and which is called "int".
>>>>
>>>> I think that your requirements are already met, with the exception that
>>>> the integer type is called
>>>> size_t
>>>> instead of
>>>> int
>>>
>>>ptrdiff_t is the int-counterpart that fits in a general purpose
>>>register. size_t is unsigned.
>>
>> Of course, one can alway use ssize_t.
>
>No, one can't always use ssize_t. It's defined by POSIX, not by ISO C
>(even in the latest C23 draft), and POSIX doesn't guarantee that it's
>the signed type corresponding to size_t.

Yes, one can always use ssize_t.

typedef signed long int ssize_t;