Re: We have a new standard!

On Mon, 30 Dec 2024 17:15:43 +0100
David Brown <david.brown@hesbynett.no> wrote:

On 30/12/2024 12:25, Michael S wrote:

On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <david.brown@hesbynett.no> wrote:
 
 
Comments after cursory view:
 
C++20 introduces two promising language features - concepts and
coroutines. Both were introduces without proper support in standard
library. Absence of support in library in both cases was justified
by probably correct claim that the best library constructs are
still in research state, non-crystallized. The hope was that
universal availability of this features at compiler level will help
to best library constructs to mature.
 
In case of coroutines developers were left with choice of 3 options:
1. To write a lot of boiler-plate code each time they a going to use
coroutines.
2. To try to organize repetitive patterns in the library (likely
template library) of their own and reuse it between parts of the
programs and multiple projects. Hopefully, share with community.
Hopefully, under liberal license.
3. Don't use coroutines
 
In case of concepts, the choice was even narrower:
1. Use concepts when you occasionally are writing container-like or
algorithm-like template of your own.
2. Don't use concepts.
 
Nobody was realistically expecting that grassroots developers will
use concepts to develop comprehensive widely reusable library that
duplicates functionality of STL, but brings advantage of sane error
messages.
 
 
So, where we are 3 years later?
W.r.t. concepts, in the same unfortunate place.
W.r.t. coroutines, library provides std::generator. I didn't look
at it yet. Hopefully, it works. Hopefully it is easy to use. But it
is just one of many possible uses of coroutines, and I would think
that it is not the one that could be considered most common.
 
 
Did I miss something?
 

 

<snip>

 
I have no experience with coroutines, so I can't really judge them.
They do not appear to me to be a "thread alternative" - rather, they
are trying to get the kind of lightweight asynchronous support that
is increasingly popular in other languages (Python, Go, Javascript,
etc.). Like C++ threading, locks and atomics, they don't really fit
in the kind of system I work with.
 

The version of coroutines that founded its way into C++ has its roots
in C# (or may be in F#, but  F# being primarily functional, is so
different that it's hard to be sure). Actually, in C# they appeared
first under not particularly illuminating name 'Iterators' (a.k.a.
IEnumerable<T>) and later on as a part of Async/Await pattern. Python
and Javascript (and Swift and Rust? I am not sure about it.) borrowed
from C#. Go goroutines (that were very recently borrowed by Java under
the name 'virtual threads') are quite different.

Although it is true that main motivation of people that initiated
inclusion of coroutines in C++ is implementation of of async/await and
of "iterators" (in C++, following Python, I suppose, they are named
'generators') they certainly can be used for other things too.
In particular, C++ coroutines can be utilized for implementing things
that today tend to be written as state machines, in almost sequential
coding style. In this role they look like a useful tool for "neither
big nor tiny" sort of embedded software that, according to my
understanding, happens to be the job that pays your bills.

Originally, I wanted to give an example of bit-banging implementation
of monitoring of pair of different I2C temperature sensors attached to
independent buses, written as a couple of C++ coroutines called from
one low-priority task of real-time executive. But then I reconsidered.
It's to much work and unlikely to be read by many. Plus, I am rather
bad writer.
May be, later I'd give simpler examples of what I mean.
Or, preferably, you and other readers figure it out by yourselves. The
latter is better pedagogically. That is, except for myself.