Worst thing about 2020 C++

[woodb...@gmail.com]

Shalom

What do you think is the worst thing about 2020 C++?
I'd say it's the lack of static exceptions. Are Clang
or Gcc making any progress with that in spite of 2020
C++?


Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards

[Sam]

woodb...@gmail.com writes:

> Shalom
>
> What do you think is the worst thing about 2020 C++?
> I'd say it's the lack of static exceptions. Are Clang
> or Gcc making any progress with that in spite of 2020
> C++?

Co-routines is the undisputed winner, hands down. A solution in search of a
problem.

If I was on the committee and ate some mushrooms, this is what I would come
up with.

[Paavo Helde]

13.08.2020 01:28 Sam kirjutas:
> woodb...@gmail.com writes:
>
>>  Shalom
>>
>> What do you think is the worst thing about 2020 C++?
>> I'd say it's the lack of static exceptions.  Are Clang
>> or Gcc making any progress with that in spite of 2020
>> C++?
>
> Co-routines is the undisputed winner, hands down. A solution in search
> of a problem.

More like a solution which you need to poorly reinvent or work around
when you don't realize you have *this* problem.

If you don't have use for co-routines this does not mean nobody does.
For example, I have not found use for std::list and I'm not complaining.

[Alf P. Steinbach]

Let's call it the continuations API.

Because it's not support for general coroutines, just the special case
of continuations (a.k.a. stackless coroutines).


- Alf

[Brian Wood]

Years ago Gcc and Clang were making some progress on
static exceptions. I'm wondering if that work has been
totally derailed now by 2020 C++.


Brian
Ebenezer Enterprises

[Juha Nieminen]

Paavo Helde <ees...@osa.pri.ee> wrote:
>> Co-routines is the undisputed winner, hands down. A solution in search
>> of a problem.
>
> More like a solution which you need to poorly reinvent or work around
> when you don't realize you have *this* problem.
>
> If you don't have use for co-routines this does not mean nobody does.
> For example, I have not found use for std::list and I'm not complaining.

It took me some time to understand what coroutines are good for, but
once I figured out this practical example, I think it' makes it quite
clear. (I have mentioned this in the past, but I suppose it doesn't
hurt repeating.)

Suppose you are decompressing a file (or compressed data that's
coming in or whatever). You have a fixed-sized array into which
you are storing the decompressed data. The idea is that once the
array gets full, you should call some "consumer" code that handles
the uncompressed data (and thus "empties" the array of it), after
which you continue decompressing more data into it.

The thing is, compressed data tends to be in some kind of chunks,
ie. when you decompress one "unit" if compressed data, the resulting
decompressed data may not fit neatly in the array, filling it
completely (or fitting inside it in the first place, even if the
array was empty). You would need to partially decompress this
chunk of compressed data and fill the array with the decompressed
data, call the "consumer" code, and then continue decompressing
from where you left (now filling the array from the beginning).

In other words, you need to be able to stop decompressing somewhere
in the middle of your decompression routine, call the outside code,
and then resume from where you left.

Normally this means that you need to store the entire state of your
decompressor somewhere, and then code the logic that allows you to
continue from where you left off. This becomes quite complicated
if there are many points in the decompressor code where the output
array may get full and thus it needs to stop, call the "consumer",
and then continue.

This is where coroutines step in to largely automatize this entire
process. At any point in your decompressor, if the output array may
get full, you simply "yield", and then continue as normal. You don't
need to keep the entire decompressor state stored somewhere, you don't
need to remember which "yield" point you were last in, you don't need
to code any logic to jump back to that particular "yield" point.
Coroutines take care of all that automatically for you.

It is, of course, perfectly possible to do all this without
coroutines, but it's much more laborious. Coroutines automatize
most of this.

[Alf P. Steinbach]

It used to be called a Jackson (data) "structure clash" problem. Not
after Michael Jackson, but after the Jackson who invented manually
structured Cobol programming. I remember that some years ago it was
already very difficult to convince Mr. Google to find anything about it,
but at one time just about every corporate developer knew about it.

- Alf

[Jorgen Grahn]

I don't know anything about the feature, but it's normal for a new
language feature to get prototyped in either of those compilers. Then
people play with it, and if enough like it, it ends up in the
language.

Compiler-specific extensions haven't been popular in recent decades,
so if it turns out the feature won't be standardized, it probably
won't make it to a real g++ or clang release.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Sam]

Paavo Helde writes:

> 13.08.2020 01:28 Sam kirjutas:
>> woodb...@gmail.com writes:
>>
>>>  Shalom
>>>
>>> What do you think is the worst thing about 2020 C++?
>>> I'd say it's the lack of static exceptions.  Are Clang
>>> or Gcc making any progress with that in spite of 2020
>>> C++?
>>
>> Co-routines is the undisputed winner, hands down. A solution in search of a
>> problem.
>
> More like a solution which you need to poorly reinvent or work around when
> you don't realize you have *this* problem.

I have no idea where I would be without someone telling me that I have some
problem I don't know about.

Probably sitting in a dark room, pulling my hair out, or something, living
in perpetual fear of all these hidden problem boogeymen.

[Sam]

Juha Nieminen writes:

> Paavo Helde <ees...@osa.pri.ee> wrote:
> >> Co-routines is the undisputed winner, hands down. A solution in search
> >> of a problem.
> >
> > More like a solution which you need to poorly reinvent or work around
> > when you don't realize you have *this* problem.
> >
> > If you don't have use for co-routines this does not mean nobody does.
> > For example, I have not found use for std::list and I'm not complaining.
>
> It took me some time to understand what coroutines are good for, but
> once I figured out this practical example, I think it' makes it quite
> clear. (I have mentioned this in the past, but I suppose it doesn't
> hurt repeating.)
>
> Suppose you are decompressing a file (or compressed data that's

Or, instead of doing all of this, implement a push-based API.

> It is, of course, perfectly possible to do all this without
> coroutines, but it's much more laborious. Coroutines automatize
> most of this.

Gee, that's neat. Almost as neat as throw specifications. Oh, wait…

[Juha Nieminen]

Sam <s...@email-scan.com> wrote:
>> It is, of course, perfectly possible to do all this without
>> coroutines, but it's much more laborious. Coroutines automatize
>> most of this.
>

> Gee, that's neat. Almost as neat as throw specifications. Oh, wait???

Sounds more like the stubborn people who complain about all changes will
refuse to use it, while people who understand the use of the feature
will save themselves a lot of trouble by just using it.

It's like those C hackers who always complain how templates are too
complicated and how they love to make everything by hand in C, while
experienced C++ programmers will just use templates without much
problems and get things done much easier and faster (and often
even producing a more efficient result).

[red floyd]

On 8/14/2020 4:11 AM, Sam wrote:


> I have no idea where I would be without someone telling me that I have
> some problem I don't know about.
>
> Probably sitting in a dark room, pulling my hair out, or something,
> living in perpetual fear of all these hidden problem boogeymen.
>
>

So if you don't have a need for the feature, don't use it. Just because
it doesn't fit YOUR use case, doesn't mean that others don't like it.

Chill out, dude.

[Sam]

Juha Nieminen writes:

> Sam <s...@email-scan.com> wrote:
> >> It is, of course, perfectly possible to do all this without
> >> coroutines, but it's much more laborious. Coroutines automatize
> >> most of this.
> >
> > Gee, that's neat. Almost as neat as throw specifications. Oh, wait???
>
> Sounds more like the stubborn people who complain about all changes will
> refuse to use it, while people who understand the use of the feature
> will save themselves a lot of trouble by just using it.

I wonder how many people decided that throw specifications were the greatest
thing since sliced bread, and started sprinkling them all over the place, as
a prophylactic measure, to catch bugs earlier? Where are they now?

Or, everyone who thought that std::vector<bool> was brilliant. Very useful,
right?

[Sam]

Where did I claim that nobody liked it? I never said that. The only thing
that I said is that it's something I would've come up with myself, after
injesting a few mushrooms.

I'm sure that someone, some time ago, really liked `std::vector<bool>`, and
thought that it was the greatest invention that humankind ever made.

I'm sure that there will be those that, for whatever reasons, like co-
routines, and start cranking them out like they're going out of style. Bless
their little hearts.

I really don't understand why someone would get so disjointed in response to
my disparaging remarks. I'm humbled at the thought that someone values my
opinions so much that they get enturbulated when I dis their favorite toys.

If someone started bad-mouthing, for example, real execution threads –
which is something that I'm very found of – I don't think I'd care. I'd
read the rant, smirk, and move on. Why would I care about some other rando's
stream of consciousness? Who are they to me? Nobody. Why should I care?
Can't think of a reason.

> Chill out, dude.

I'm perfectly chilled.

[Jorgen Grahn]

On Fri, 2020-08-14, Sam wrote:
> Juha Nieminen writes:
...

>> It is, of course, perfectly possible to do all this without
>> coroutines, but it's much more laborious. Coroutines automatize
>> most of this.
>

> Gee, that's neat. Almost as neat as throw specifications. Oh, wait=E2=80=A6

With that reasoning, you could argue that C++ should have stopped
evolving with "C with classes" around 1980 ...

[Jorgen Grahn]

He kind of /does/ have a point, though. How do I know I can make my
code better by applying some new language feature? There are
countless C programmers implementing linked lists right now; we'd just
use a std::vector and not even notice.

I want new language features to fall into the classes:
A - Major and really useful to many people.
B - Minor, easy to adopt.
C - Fringe features, easy to ignore.

I haven't investigated coroutines yet; I hope they are in class A.

[Sam]

Jorgen Grahn writes:

> On Fri, 2020-08-14, Sam wrote:
> > Juha Nieminen writes:
> ...
> >> It is, of course, perfectly possible to do all this without
> >> coroutines, but it's much more laborious. Coroutines automatize
> >> most of this.
> >
> > Gee, that's neat. Almost as neat as throw specifications. Oh, wait=E2=80=A6
>
> With that reasoning, you could argue that C++ should have stopped
> evolving with "C with classes" around 1980 ...

You might not be aware of this, but throw specifications have been
deprecated, and are completely gone in C++20. They turned out to be quite a
dumpster fire.

This was a completely blown, golden opportunity to add strong exception
correctness checking to the core language, simply by aping what Java does.
Instead throw specification became weak-ass nothing-burgers, that brought
absolutely nothing value-added to to the table. All they did was force a
runtime abort when the specification was violated. As Benny Hill would've
said: biiiiiiiiiiiiiiiiig ...deal.

Wouldn't it be nice to be able to prove, at /compile time/, that all
exceptions get caught and handled properly? Simply by making main
automatically be throw(), and thus forcing all the knuckleheads to catch
their exceptions /or the code won't compile/? Oh, well, it's just a nice
dream now…

But the bottom line is just because something's been added to the core
language doesn't mean it's the greatest thing since sliced bread. The bumpy
road of C++'s evolution has its share of piles of flaming crap, still
smoldering, in the rear-view mirror. I predict the co-routines will turn out
to be another pile.

[Paavo Helde]

16.08.2020 05:25 Sam kirjutas:
> Jorgen Grahn writes:
>
>> On Fri, 2020-08-14, Sam wrote:
>> > Juha Nieminen writes:
>> ...
>> >> It is, of course, perfectly possible to do all this without
>> >> coroutines, but it's much more laborious. Coroutines automatize
>> >> most of this.
>> >
>> > Gee, that's neat. Almost as neat as throw specifications. Oh,
>> wait=E2=80=A6
>>
>> With that reasoning, you could argue that C++ should have stopped
>> evolving with "C with classes" around 1980 ...
>
> You might not be aware of this, but throw specifications have been
> deprecated, and are completely gone in C++20. They turned out to be
> quite a dumpster fire.
>
> This was a completely blown, golden opportunity to add strong exception
> correctness checking to the core language, simply by aping what Java
> does. Instead throw specification became weak-ass nothing-burgers, that
> brought absolutely nothing value-added to to the table. All they did was
> force a runtime abort when the specification was violated. As Benny Hill
> would've said: biiiiiiiiiiiiiiiiig ...deal.

Agreed, C++ throw specifications were a disaster. However, strong
exception correctness would have been even worse. Maintenance nightmare
for very little gain, and cannot be properly applied to templates,
virtual functions and shared libraries, so it would have remained
half-baked anyway.

>
> Wouldn't it be nice to be able to prove, at /compile time/, that all
> exceptions get caught and handled properly? Simply by making main
> automatically be throw(), and thus forcing all the knuckleheads to catch
> their exceptions /or the code won't compile/? Oh, well, it's just a nice
> dream now…

It's very easy to prove at compile time (or even before compile time)
that all exceptions are caught and handled, just add catch(...) to main().

>
> But the bottom line is just because something's been added to the core
> language doesn't mean it's the greatest thing since sliced bread. The
> bumpy road of C++'s evolution has its share of piles of flaming crap,
> still smoldering, in the rear-view mirror. I predict the co-routines
> will turn out to be another pile.

Unlike throw specifications, co-routines do not interfere with other
code which doesn't use them, so they really cannot become such a
smoldering pile. At worst they could become a small unused pile similar
to trigraphs.

[Sam]

Paavo Helde writes:

> Agreed, C++ throw specifications were a disaster. However, strong exception
> correctness would have been even worse. Maintenance nightmare for very
> little gain, and cannot be properly applied to templates, virtual functions
> and shared libraries, so it would have remained half-baked anyway.

I'm not sure why they would be a maintenance nightmare. It's not like
existing code somehow decides to throw exceptions that it didn't before, all
the time.

And I do not see why strong exception checking would have a problem with
templates, or virtual functions, or shared libraries. After all, the sole
remaining survivor of that epic fail, the noexcept keyword, is perfectly
happy keeping them all company. Ignoring the fact that you can still stick a
throw inside a noexcept, and it compiles, the noexcept keyword works just
fine. With templates or without them. With virtual functions or without them.

>> Wouldn't it be nice to be able to prove, at /compile time/, that all
>> exceptions get caught and handled properly? Simply by making main
>> automatically be throw(), and thus forcing all the knuckleheads to catch
>> their exceptions /or the code won't compile/? Oh, well, it's just a nice
>> dream now…
>
> It's very easy to prove at compile time (or even before compile time) that
> all exceptions are caught and handled, just add catch(...) to main().

Not if one gets thrown inside a noexcept function. Now you've got an aborted
program, instead of a nicely caught exception.

[Paavo Helde]

16.08.2020 15:36 Sam kirjutas:
> Paavo Helde writes:
>
>> Agreed, C++ throw specifications were a disaster. However, strong
>> exception correctness would have been even worse. Maintenance
>> nightmare for very little gain, and cannot be properly applied to
>> templates, virtual functions and shared libraries, so it would have
>> remained half-baked anyway.
>
> I'm not sure why they would be a maintenance nightmare. It's not like
> existing code somehow decides to throw exceptions that it didn't before,
> all the time.

But they do. Third-party libraries get new versions which might throw
new exceptions. Or what happens more often, I add a new class overriding
some virtual function which is throwing a new exception which is not
listed in the base class contract.

>
> And I do not see why strong exception checking would have a problem with
> templates, or virtual functions, or shared libraries. After all, the
> sole remaining survivor of that epic fail, the noexcept keyword, is
> perfectly happy keeping them all company. Ignoring the fact that you can
> still stick a throw inside a noexcept, and it compiles, the noexcept
> keyword works just fine. With templates or without them. With virtual
> functions or without them.

Knowing that a function cannot throw at all is a useful piece of
information and indeed needed in some circumstances. However, this need
appears only rarely and what's more important, it does not require to
decorate the rest of the codebase with useless throw specifications.

>
>>> Wouldn't it be nice to be able to prove, at /compile time/, that all
>>> exceptions get caught and handled properly? Simply by making main
>>> automatically be throw(), and thus forcing all the knuckleheads to
>>> catch their exceptions /or the code won't compile/? Oh, well, it's
>>> just a nice dream now…
>>
>> It's very easy to prove at compile time (or even before compile time)
>> that all exceptions are caught and handled, just add catch(...) to
>> main().
>
> Not if one gets thrown inside a noexcept function. Now you've got an
> aborted program, instead of a nicely caught exception.

That's one more reason to keep the usage of noexcept at minimum and
tightly controlled. A compile-time error would be better indeed in this
case.

[bol...@nowhere.co.uk]

As of the latest MacOS 10.15.6 Clang still doesn't support co-routines
properly and gcc (whatever version, didn't check) in the latest debbie
update of Linux Mint doesn't either though AFAIK VC++ does so a win for MS
there for once. However it means co-routines still can't be used for any
portable code so perhaps they'll die before ever becoming mainstream.

[Sam]

Paavo Helde writes:

> 16.08.2020 15:36 Sam kirjutas:
>> Paavo Helde writes:
>>
>>> Agreed, C++ throw specifications were a disaster. However, strong exception
>>> correctness would have been even worse. Maintenance nightmare for very
>>> little gain, and cannot be properly applied to templates, virtual functions
>>> and shared libraries, so it would have remained half-baked anyway.
>>
>> I'm not sure why they would be a maintenance nightmare. It's not like
>> existing code somehow decides to throw exceptions that it didn't before, all
>> the time.
>
> But they do. Third-party libraries get new versions which might throw new
> exceptions.

And then the existing code will not recompile. So you know that you need to
fix it.

I don't see how that's any different from any other API change.

In fact, I would /like it very much/ if it were to happen. As compared to
the current situation, where I"m catching the exceptions that are documented
by the API. So, everything goes along swimmingly well. Until the new version
of this "third party library" starts throwing a different exception, and I
missed the memo. So now I'm boned. abort().

I would /very much prefer/ to have the compiler tell me: yo, dude, new
exception, you have no handler for it, so no soup for you.

So, I very much /like/ having this kind of maintenance foisted on me, where
I /know/ I need to do some maintenance, in order to have things continue to
work.

[Sam]

bol...@nowhere.co.uk writes:

> As of the latest MacOS 10.15.6 Clang still doesn't support co-routines
> properly and gcc (whatever version, didn't check) in the latest debbie
> update of Linux Mint doesn't either though AFAIK VC++ does so a win for MS
> there for once. However it means co-routines still can't be used for any
> portable code so perhaps they'll die before ever becoming mainstream.

I hope so. This thread finally gave me sufficient motivation to chase down
where the co-routine idiocy originated. I strongly suspected it was more
Microsoft-lobbied crap.

I was right.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4775.pdf

So, it shouldn't be surprising to see that Microsoft's compiler already
implements this garbage. Which is more supporting evidence that it's crap,
and will always be crap.

I wouldn't lose any sleep if gcc never implements co-routines.

But it probably will, at some point. gcc currently lacks support for some
C++ library functionality that I sorely miss. Hopefully those gaps will be
priority, then this nosense.

[Vir Campestris]

On 14/08/2020 05:52, Alf P. Steinbach wrote:
>
> It used to be called a Jackson (data) "structure clash" problem. Not
> after Michael Jackson, but after the Jackson who invented manually
> structured Cobol programming. I remember that some years ago it was
> already very difficult to convince Mr. Google to find anything about it,
> but at one time just about every corporate developer knew about it.

Actually it _was_ after Michael Jackson.

Just not the one normal people have heard of...

https://en.wikipedia.org/wiki/Jackson_structured_programming

Andy

[bol...@nowhere.co.uk]

On Sun, 16 Aug 2020 16:15:51 -0400
Sam <s...@email-scan.com> wrote:
>This is a MIME GnuPG-signed message. If you see this text, it means that
>your E-mail or Usenet software does not support MIME signed messages.
>The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
>To open this message correctly you will need to install E-mail or Usenet
>software that supports modern Internet standards.
>
>--=_monster.email-scan.com-35748-1597608951-0002
>Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
>Content-Disposition: inline
>Content-Transfer-Encoding: 7bit

>
>bol...@nowhere.co.uk writes:
>
>> As of the latest MacOS 10.15.6 Clang still doesn't support co-routines
>> properly and gcc (whatever version, didn't check) in the latest debbie
>> update of Linux Mint doesn't either though AFAIK VC++ does so a win for MS
>> there for once. However it means co-routines still can't be used for any
>> portable code so perhaps they'll die before ever becoming mainstream.
>
>I hope so. This thread finally gave me sufficient motivation to chase down
>where the co-routine idiocy originated. I strongly suspected it was more
>Microsoft-lobbied crap.

Yeah, I can't say I'm a fan either. They have a use case but so does setjmp/
longjmp and I wouldn't use them either unless I absolutely had no other
choice (not happened yet).

>But it probably will, at some point. gcc currently lacks support for some
>C++ library functionality that I sorely miss. Hopefully those gaps will be
>priority, then this nosense.

Clang hasn't even implemented <=> yet which should be trivial. Not sure about
gcc.

[Brian Wood]

Yeah, whether it's auto, std::string, etc., it's easy to overdo it.


Brian
Ebenezer Enterprises - Life is fragile; handle with prayer.
https://github.com/Ebenezer-group/onwards

[Brian Wood]

I've not investigated them a lot, but from what I can tell
so far, they aren't going to be useful to me in this program:

https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc


Brian
Ebenezer Enterprises - In G-d we trust.

[Sam]

bol...@nowhere.co.uk writes:

> >I hope so. This thread finally gave me sufficient motivation to chase down
> >where the co-routine idiocy originated. I strongly suspected it was more
> >Microsoft-lobbied crap.
>
> Yeah, I can't say I'm a fan either. They have a use case but so does setjmp/

Their use case is that multi-threaded performance on MS-Windows is notorious
for being utterly craptastic; thread creation takes an eternity, etc…

This is just Microsoft attempting to stuff the C++ standard with a
multithreaded-like API that doesn't suck on Windows.

> >But it probably will, at some point. gcc currently lacks support for some
> >C++ library functionality that I sorely miss. Hopefully those gaps will be
> >priority, then this nosense.
>
> Clang hasn't even implemented <=> yet which should be trivial. Not sure about
> gcc.

gcc has it.

[Juha Nieminen]

Sam <s...@email-scan.com> wrote:
> So, it shouldn't be surprising to see that Microsoft's compiler already
> implements this garbage. Which is more supporting evidence that it's crap,
> and will always be crap.

Did you have an actual argument against them, or are you just going to throw
tantrums and insults like a petulant child?

[David Brown]

There is also the obvious counter-argument that MS did not in any sense
"invent" coroutines. Amongst others, they are discussed by Knuth - who
describes subroutines (i.e., "functions" in C and C++) as just being
special cases of coroutines.

[Alf P. Steinbach]

The C++20 coroutines API (which is a misnomer because it does not
support general coroutines but just continuations) devolved directly
from Microsoft's API shipped with Visual C++ for a number of years.

The standardization committee managed to uglify it considerably, in
addition to its inherent ugliness, including uglification of keywords.

But the changes are superficial, cosmetic: it is thoroughly a Microsoft
thing, and arguing against that fact is, well, un-informed. ;-)

- - -

I did not myself implement but helped to implement coroutines in some
microprocessor assembly (could it be Z80?) + Pascal in the early 1980's,
at college. We had nice HP 64000 workstations... :)

The only language I've used with real support for co-routines is
Modula-2, which I used as a student in Edinburgh late 1980's on my first
computer, an Atari 1040ST.

I then implemented real co-routines for Turbo C++ in the 1990's, based
on `longjmp` and some assembly.

Unfortunately that TC++ code was enthusiastically used by someone
working at a hospital in New York. I hope that code didn't hurt anyone. But.

So, I have "always" found co-routines interesting and sort of useful,
sort of seeking them out, testing the feel of them. But I find the C++20
thing disgusting. It does not appeal to me at all.


- Alf

[Juha Nieminen]

It would be hard to argue that Microsoft invented coroutines given that they
were first discussed as far back as in 1958, and languages like Simula 67,
BCPL and Modula-2 have support for coroutines.

[bol...@nowhere.co.uk]

On Sun, 16 Aug 2020 19:58:52 -0400
Sam <s...@email-scan.com> wrote:
>Their use case is that multi-threaded performance on MS-Windows is notori=
>ous =20
>for being utterly craptastic; thread creation takes an eternity, etc=E2=80=
>=A6

Though I suspect not as bad as the utterly hopeless win32 process creation
model.

[Sam]

Yes, I do: they suck.

[Sam]

David Brown writes:

> On 17/08/2020 07:58, Juha Nieminen wrote:
> > Sam <s...@email-scan.com> wrote:
> >> So, it shouldn't be surprising to see that Microsoft's compiler already
> >> implements this garbage. Which is more supporting evidence that it's crap,
> >> and will always be crap.
> >
> > Did you have an actual argument against them, or are you just going to
> throw
> > tantrums and insults like a petulant child?
> >
>
> There is also the obvious counter-argument that MS did not in any sense
> "invent" coroutines.

Nobody claimed that they did. They simply crammed it into the C++ standard
because Windows sucks at doing actual threads.

[Juha Nieminen]

So a petulant child you are. I will thus be treating you as one.

[Sam]

You are operating under an impression that I value your opinions very
highly. Not sure where you got that impression from.

[red floyd]

On 8/16/2020 11:24 PM, David Brown wrote:
>
> There is also the obvious counter-argument that MS did not in any sense
> "invent" coroutines. Amongst others, they are discussed by Knuth - who
> describes subroutines (i.e., "functions" in C and C++) as just being
> special cases of coroutines.
>

In addition, Coroutines (called Tasks) were actually part of Modula-2
language specification (as of 1983).

[red floyd]

Pardon me, they were called "Processes"

[Alf P. Steinbach]

They were called coroutines.

Possibly you're thinking of Modula-2's asynchronous coroutines.

There was a book about development in Modula-2 I had (still have in a
box somewhere) called "Modula-2: A Software Development Approach" by
Ford & Wiener, which presented an abstraction over coroutines and
asynchronous interrupt-driven coroutines. A kind of threading
abstraction where at the higher levels you code up things without
knowing whether it will execute all in one single thread or in several,
whatever.

It's an old idea, e.g. one Algol compiler in the early 1960's was based
on coroutines where it could execute either as one single process, or as
sequentially invoked multiple phases.

I mentioned the Modula-2 abstraction idea to Bjarne when he presented
`std::future` and friends in Oslo mid 2000's. However, he appeared just
perplexed at my enthusiasm for the idea. At that time coroutines were
not yet on the table for C++, so maybe discussing an abstraction over
something he presented + something not yet envisioned, was premature...


- Alf