On 03/03/2022 21:57, Scott Lurndal wrote:
> 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;

On 64-bit Windows, that declares a 32-bit type.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

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

No. It's about what can be used, not what must be used. It need
involve no source code changes at all, but it does mean that C11
features could be used in the future. And the change signals what is
the oldest version of gcc that needs to be supported.

--
Ben.

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
[...]
>>>>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;

Presumably surrounded by a nest of #ifdefs so you don't (a) redefine it
when the implementation already defines it or (b) define it with the
wrong size (on Windows, for example, size_t is 64 bits and long int is
32 bits).

--
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 21:31, Ben Bacarisse wrote:
> 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.)

Yes.

>
> 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 agree with that guess - it would be my guess too! I haven't tried any
ranges stuff as yet, other than a "drop(1)" added to the first set of
example code I made. Testing on godbolt showed exactly the same code,
IIRC - it seems gcc not only optimises this all to the same kind of loop
you'd get with a traditional dedicated C function, but it was also smart
enough to spot the "max" pattern and skip the unnecessary first round.

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

To be honest, I can't remember the details of the syntax from the
functional programming language I used at university (it was called
"Orwell", but it was only much used at Oxford and Glasgow universities.
They have both standardised on Haskell now, AFAIK. But you are of
course right - "head : tail" is used for pattern matching, and " ++ " is
the concatenation operator. I am out of practice!

I find threads like this inspirational for looking at new features of
languages or libraries and trying them out. It is, however, wandering a
bit from comp.lang.c - despite Malcolm's attempts to bring it back!

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

I thought it was interesting to write it in the "piped filter" pattern,
and to see how that looked in the generated code (fully optimised, in
the simple cases I tried). I haven't used this kind of thing in real
code as yet.

On 03/03/2022 22:47, Bart wrote:
> On 03/03/2022 21:35, Vir Campestris wrote:

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

No, pointer /sizes/ and array index /sizes/ can be completely different.
What you mean, I think, is that the /range/ you have by using array
indexes or by using pointers into an array should be the same. In C,
given the way array indexing is defined and the rules about which
pointer accesses are fully defined, these ranges are the same even on
targets where pointers are bigger than size_t.

On 04/03/2022 08:46, David Brown wrote:
> On 03/03/2022 22:47, Bart wrote:
>> On 03/03/2022 21:35, Vir Campestris wrote:
>
>>> 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.
>>
>
> No, pointer /sizes/ and array index /sizes/ can be completely different.
> What you mean, I think, is that the /range/ you have by using array
> indexes or by using pointers into an array should be the same. In C,
> given the way array indexing is defined and the rules about which
> pointer accesses are fully defined, these ranges are the same even on
> targets where pointers are bigger than size_t.

What I mean is, even if array indices were say 64 bits, and pointers
were 256 bits, the programmer can be given a 64-bit reference to such a
pointer. Then both indices and 'pointers' are the same size.

The implementation however then has the headache of turning pointer
accesses into double-dereferences: from 64-bit 'pointer' to 256-bit true
pointer to the actual data.

Am 03.03.2022 um 21:59 schrieb Chris M. Thomasson:
> 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.

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

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

> To be honest, I can't remember the details of the syntax from the
> functional programming language I used at university (it was called
> "Orwell", but it was only much used at Oxford and Glasgow
> universities.

Orwell used the (hd:tail) pattern as well. All of that family (SASL,
KRC, Miranda, Orwell, Haskell) are very similar.

> ... It is, however, wandering a
> bit from comp.lang.c - despite Malcolm's attempts to bring it back!

ACK. I think there's been enough drift.

--
Ben.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>[...]
>>>>>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;
>
>Presumably surrounded by a nest of #ifdefs so you don't (a) redefine it
>when the implementation already defines it or (b) define it with the
>wrong size (on Windows, for example, size_t is 64 bits and long int is
>32 bits).

In 40 years of C programming, I've never encountered (outside of a
classroom) a C program that doesn't rely on either Unix/POSIX interfaces,
Windows APIs or some other third-party API.

So yes, one would need the appropriate code for the target platform.

On Friday, 4 March 2022 at 15:40:51 UTC, Scott Lurndal wrote:
> Keith Thompson <Keith.S.T...@gmail.com> writes:
> >sc...@slp53.sl.home (Scott Lurndal) writes:
> >> Keith Thompson <Keith.S.T...@gmail.com> writes:
> >>>sc...@slp53.sl.home (Scott Lurndal) writes:
> >>>> Bonita Montero <Bonita....@gmail.com> writes:
> >[...]
> >>>>>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;
> >
> >Presumably surrounded by a nest of #ifdefs so you don't (a) redefine it
> >when the implementation already defines it or (b) define it with the
> >wrong size (on Windows, for example, size_t is 64 bits and long int is
> >32 bits).
> In 40 years of C programming, I've never encountered (outside of a
> classroom) a C program that doesn't rely on either Unix/POSIX interfaces,
> Windows APIs or some other third-party API.
>
> So yes, one would need the appropriate code for the target platform.
>
Here's one by me.
https://github.com/MalcolmMcLean/babyxrc

It's a resource compiler. It pulls in images, fonts, string, and audio clips.
Then it dumps them as C source files consisting of data definitions.
it allows simple resizing, but not a full image-processing chain.

It's designed for use by Baby X, but can be used for other programs.

scott@slp53.sl.home (Scott Lurndal) writes:

> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 02.03.2022 um 05:45 schrieb Lynn McGuire:

[...]

>>> What is your definition of a modern language ?
>>
>> OOP,
>
> Simula, 1967.
>
>
>> RAII,
>
> ADA, 1980.

I think it was done earlier in other languages, although
I don't have a specific reference.

>> generic programming,
>
> ML, 1973.
>
>> functional programming,
>
> Lisp, 1970's.

Lisp goes back to 1958, the second oldest programming
language still in common use.