Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #81356 > unrolled thread

"C++20 Coroutines" by Martin Bond

Back to article view | Back to comp.lang.c++

Contents

  "C++20 Coroutines" by Martin Bond Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-20 16:30 -0500
    Re: "C++20 Coroutines" by Martin Bond Bo Persson <bo@bo-persson.se> - 2021-09-21 09:28 +0200
    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-21 11:45 +0200
      Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-21 15:37 +0000
        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-21 17:40 +0200
        Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-22 05:22 +0000
          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-22 09:26 +0000
            Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-22 16:40 +0200
              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-22 15:01 +0000
                Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-23 05:38 +0200
                  Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 09:05 +0000
                    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:15 +0200
                      Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 00:57 +0000
                  Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-23 09:11 +0000
                    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:17 +0200
                      Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 09:19 +0000
                        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 12:00 +0200
                          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 10:09 +0000
                            Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 12:18 +0200
                              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 10:39 +0000
                                Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 12:42 +0200
                                  Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 10:44 +0000
                                    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 13:14 +0200
                                      Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:44 +0000
                                        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 15:58 +0200
                                          Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 13:59 +0000
                                            Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 16:23 +0200
                                              Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 07:24 +0200
                                          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 15:28 +0000
                                      Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 15:04 +0000
                                        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 18:44 +0200
                                          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-26 14:15 +0000
                        Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:32 +0000
            Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:42 +0000
              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-23 09:14 +0000
                Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-24 04:42 +0000
              Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:19 +0200
                Re: "C++20 Coroutines" by Martin Bond Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-24 21:07 +0100
                  Re: "C++20 Coroutines" by Martin Bond Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:19 -0700
                Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 00:58 +0000
                  Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:39 +0000
                    Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 02:30 +0000
                Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 09:20 +0000
          Re: "C++20 Coroutines" by Martin Bond "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 11:31 +0200
        Re: "C++20 Coroutines" by Martin Bond Sam <sam@email-scan.com> - 2021-09-22 18:43 -0400
          Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:45 +0000
            Re: "C++20 Coroutines" by Martin Bond "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-23 01:53 -0700
            Re: "C++20 Coroutines" by Martin Bond Sam <sam@email-scan.com> - 2021-09-24 19:21 -0400
              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 09:28 +0000
                Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:38 +0000
              Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:42 +0000
    Re: "C++20 Coroutines" by Martin Bond "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-25 15:14 +0200
      Re: "C++20 Coroutines" by Martin Bond Manfred <noname@add.invalid> - 2021-09-25 23:07 +0200
        Re: "C++20 Coroutines" by Martin Bond "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-26 01:50 +0200
          Re: "C++20 Coroutines" by Martin Bond Manfred <noname@add.invalid> - 2021-09-26 19:12 +0200

Page 1 of 3  [1] 2 3  Next page →

#81356 — "C++20 Coroutines" by Martin Bond

"C++20 Coroutines" by Martin Bond
    https://blog.feabhas.com/2021/09/c20-coroutines/

"There seems to be a lot of confusion around the implementation of C++20 
coroutines, which I think is due to the draft technical specification 
for C++20 stating that coroutines are a work in progress so we can’t 
expect full compiler and library support at this point in time.
A lot of the problems probably arise from the lack of official 
documentation about working with coroutines. We have been given C++ 
syntax support for coroutines (the co_yield and co_return) but without 
all of what I consider full library support. The standard library has 
hooks and basic functionality for supporting coroutines, but we must 
incorporate this into our own classes. I anticipate that there will be 
full library support for generator style coroutines in C++23."

Lynn

[toc] | [next] | [standalone]

#81363

On 2021-09-20 at 23:30, Lynn McGuire wrote:
> "C++20 Coroutines" by Martin Bond
>     https://blog.feabhas.com/2021/09/c20-coroutines/
> 
> "There seems to be a lot of confusion around the implementation of C++20 
> coroutines, which I think is due to the draft technical specification 
> for C++20 stating that coroutines are a work in progress so we can’t 
> expect full compiler and library support at this point in time.
 >
> A lot of the problems probably arise from the lack of official 
> documentation about working with coroutines. We have been given C++ 
> syntax support for coroutines (the co_yield and co_return) but without 
> all of what I consider full library support. The standard library has 
> hooks and basic functionality for supporting coroutines, but we must 
> incorporate this into our own classes. I anticipate that there will be 
> full library support for generator style coroutines in C++23."
> 

Yes, this seems to be one of the downsides of the current "no delays" 
method of producing the standard revisions. The train leaves the station 
on time, but not everyone made it. Some passengers didn't have all their 
baggage ready, and were left on the platform.

The opposite, of course, was the C++08 revision where the committee 
tried hard to complete everything and it turned out as C++11. Now 
everyone got on the train, but 3 years late.

Pros and cons, and all that.

[toc] | [prev] | [next] | [standalone]

#81366

Am 20.09.2021 um 23:30 schrieb Lynn McGuire:
> "C++20 Coroutines" by Martin Bond
>     https://blog.feabhas.com/2021/09/c20-coroutines/
> 
> "There seems to be a lot of confusion around the implementation of C++20 
> coroutines, which I think is due to the draft technical specification 
> for C++20 stating that coroutines are a work in progress so we can’t 
> expect full compiler and library support at this point in time.
> A lot of the problems probably arise from the lack of official 
> documentation about working with coroutines. We have been given C++ 
> syntax support for coroutines (the co_yield and co_return) but without 
> all of what I consider full library support. The standard library has 
> hooks and basic functionality for supporting coroutines, but we must 
> incorporate this into our own classes. I anticipate that there will be 
> full library support for generator style coroutines in C++23."
> 
> Lynn

Here, two parts on coroutines of two books about C++20:
https://x0.at/EwrI.pdf

[toc] | [prev] | [next] | [standalone]

#81374

On Tue, 21 Sep 2021 11:45:21 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 20.09.2021 um 23:30 schrieb Lynn McGuire:
>> "C++20 Coroutines" by Martin Bond
>>     https://blog.feabhas.com/2021/09/c20-coroutines/
>> 
>> "There seems to be a lot of confusion around the implementation of C++20 
>> coroutines, which I think is due to the draft technical specification 
>> for C++20 stating that coroutines are a work in progress so we can’t 
>> expect full compiler and library support at this point in time.
>> A lot of the problems probably arise from the lack of official 
>> documentation about working with coroutines. We have been given C++ 
>> syntax support for coroutines (the co_yield and co_return) but without 
>> all of what I consider full library support. The standard library has 
>> hooks and basic functionality for supporting coroutines, but we must 
>> incorporate this into our own classes. I anticipate that there will be 
>> full library support for generator style coroutines in C++23."
>> 
>> Lynn
>
>Here, two parts on coroutines of two books about C++20:
>https://x0.at/EwrI.pdf

Coroutines should have stayed in the microsoft world, not added to the C++
standard. They're a solution looking for a problem.

[toc] | [prev] | [next] | [standalone]

#81376

Am 21.09.2021 um 17:37 schrieb HorseyWorsey@the_stables.com:
> On Tue, 21 Sep 2021 11:45:21 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 20.09.2021 um 23:30 schrieb Lynn McGuire:
>>> "C++20 Coroutines" by Martin Bond
>>>      https://blog.feabhas.com/2021/09/c20-coroutines/
>>>
>>> "There seems to be a lot of confusion around the implementation of C++20
>>> coroutines, which I think is due to the draft technical specification
>>> for C++20 stating that coroutines are a work in progress so we can’t
>>> expect full compiler and library support at this point in time.
>>> A lot of the problems probably arise from the lack of official
>>> documentation about working with coroutines. We have been given C++
>>> syntax support for coroutines (the co_yield and co_return) but without
>>> all of what I consider full library support. The standard library has
>>> hooks and basic functionality for supporting coroutines, but we must
>>> incorporate this into our own classes. I anticipate that there will be
>>> full library support for generator style coroutines in C++23."
>>>
>>> Lynn
>>
>> Here, two parts on coroutines of two books about C++20:
>> https://x0.at/EwrI.pdf
> 
> Coroutines should have stayed in the microsoft world, not added
> to the C++ standard. They're a solution looking for a problem.

Coroutines are a solution for a problem which is very often:
state machines that need interaction with a consumer of the
states.

[toc] | [prev] | [next] | [standalone]

#81403

HorseyWorsey@the_stables.com wrote:
> Coroutines should have stayed in the microsoft world, not added to the C++
> standard. They're a solution looking for a problem.

Coroutines do solve certain problems. It's just that very few people have
ever heard of them, and they are, for some reason, generally very poorly
explained and somewhat hard to understand.

One of the major applications of coroutines is, essentially, being able to
return from a function at any given point (ie. at any point in a function
you can put a command to "return to the caller") and then the calling
code can then tell the function to continue from where it left off.
Coroutines help in, essentially, storing the entire state of the function,
so that it can continue from that exact point, using the exact same state.
Ie. execution can continue from that point forward as if the function
hadn't been exited at all.

Coroutines are compared to cooperative multitasking, and in this sense
they indeed are very similar: In cooperative multitasking at certain
points you can "yield" the execution to the OS, which then later can
return the execution back to that yield point, which will then continue
as if nothing had happened. The entire state of the process is automatically
preserved so that it can continue normally.

You *can* achieve the same effect as coroutines without them, but it
requires you to manually create the data containers where all the
necessary variables are stored so that execution can continue from
the point where it left, and you have to manually create jump statements
to wherever there are these yield points. (The more yield points there
are in your "coroutine", the more conditional gotos are required.)

One practical example of where a coroutine is useful is a library that
decompresses compressed data from a file into a buffer of fixed size.
Whenever the buffer gets full, execution is returned to the caller
for it to consume the contents of the buffer, after which the
execution is returned to the decompressor, which continues from
where it left off. However, since the buffer can typically get full at
several points in the decompressor code, even in the middle of eg.
expanding a block of data, the decompressor needs to somehow store
its exact state in order to know how to continue with the decompression
once execution is resumed. There may be several different places in
the decompression code where stuff is written to the buffer, and at
any moment the buffer may get full. Coroutines can make this whole
thing a lot simpler, as at any point you can just add a yield, with
essentially no extra work to store the state of the decompressor.

[toc] | [prev] | [next] | [standalone]

#81406

On Wed, 22 Sep 2021 05:22:59 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>You *can* achieve the same effect as coroutines without them, but it
>requires you to manually create the data containers where all the
>necessary variables are stored so that execution can continue from
>the point where it left, and you have to manually create jump statements

Isn't that the point of class methods and variables? Ie: Black boxing state.

>to wherever there are these yield points. (The more yield points there
>are in your "coroutine", the more conditional gotos are required.)

Having multiple yield points sounds like asking for sphagetti code. And thats
before you have to consider recursion in the co-routine and the effect of
threading on it (I have no idea what effects they are but I suspect its messy).

>One practical example of where a coroutine is useful is a library that
>decompresses compressed data from a file into a buffer of fixed size.
>Whenever the buffer gets full, execution is returned to the caller
>for it to consume the contents of the buffer, after which the
>execution is returned to the decompressor, which continues from
>where it left off. However, since the buffer can typically get full at
>several points in the decompressor code, even in the middle of eg.
>expanding a block of data, the decompressor needs to somehow store
>its exact state in order to know how to continue with the decompression
>once execution is resumed. There may be several different places in
>the decompression code where stuff is written to the buffer, and at
>any moment the buffer may get full. Coroutines can make this whole
>thing a lot simpler, as at any point you can just add a yield, with
>essentially no extra work to store the state of the decompressor.

Hmm, not convinced thats any simpler than using object or global state.

[toc] | [prev] | [next] | [standalone]

#81423

Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:

>> to wherever there are these yield points. (The more yield points there
>> are in your "coroutine", the more conditional gotos are required.)

> Having multiple yield points sounds like asking for sphagetti code. ...

There is no easy solution. Have you considered the altetrnative
of writing your own state-machine ? That's much worse.

[toc] | [prev] | [next] | [standalone]

#81424

On Wed, 22 Sep 2021 16:40:31 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>
>>> to wherever there are these yield points. (The more yield points there
>>> are in your "coroutine", the more conditional gotos are required.)
>
>> Having multiple yield points sounds like asking for sphagetti code. ...
>
>There is no easy solution. Have you considered the altetrnative
>of writing your own state-machine ? That's much worse.

I find state machines very clear and easy to follow as well as being explicit
rather than having some stack in an unknown (from the programmers POV) state.

[toc] | [prev] | [next] | [standalone]

#81437

Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
> On Wed, 22 Sep 2021 16:40:31 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>
>>>> to wherever there are these yield points. (The more yield points there
>>>> are in your "coroutine", the more conditional gotos are required.)
>>
>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>
>> There is no easy solution. Have you considered the altetrnative
>> of writing your own state-machine ? That's much worse.
> 
> I find state machines very clear and easy to follow as well as being explicit
> rather than having some stack in an unknown (from the programmers POV) state.

No, that's much less clearer than having a state like you're in a normal
function.

[toc] | [prev] | [next] | [standalone]

#81449

On 2021-09-23, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
>> On Wed, 22 Sep 2021 16:40:31 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>>
>>>>> to wherever there are these yield points. (The more yield points there
>>>>> are in your "coroutine", the more conditional gotos are required.)
>>>
>>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>>
>>> There is no easy solution. Have you considered the altetrnative
>>> of writing your own state-machine ? That's much worse.
>> 
>> I find state machines very clear and easy to follow as well as being explicit
>> rather than having some stack in an unknown (from the programmers POV) state.
>
> No, that's much less clearer than having a state like you're in a normal
> function.
coroutines are just same thing as threads except that cancellation points
yield context switch instead of preemptive scheduler, or this way should
be ...

--
7-77-777
\|/
---
/|\

-- 
/Volumes/air AFP Music Volume/NATASA/temp/peste noire/(2007) Folkfuck Folie/04 - D'un Vilain.mp3

[toc] | [prev] | [next] | [standalone]

#81518

Am 23.09.2021 um 11:05 schrieb Branimir Maksimovic:
> On 2021-09-23, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
>>> On Wed, 22 Sep 2021 16:40:31 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>>>
>>>>>> to wherever there are these yield points. (The more yield points there
>>>>>> are in your "coroutine", the more conditional gotos are required.)
>>>>
>>>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>>>
>>>> There is no easy solution. Have you considered the altetrnative
>>>> of writing your own state-machine ? That's much worse.
>>>
>>> I find state machines very clear and easy to follow as well as being explicit
>>> rather than having some stack in an unknown (from the programmers POV) state.
>>
>> No, that's much less clearer than having a state like you're in a normal
>> function.
> coroutines are just same thing as threads ...

No, they're similar to fiberes - with much less overhead.

[toc] | [prev] | [next] | [standalone]

#81529

And fibbers are what ? ;P 
much of muchness :P

--
7-77-777
\|/
---
/|\

On 2021-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 23.09.2021 um 11:05 schrieb Branimir Maksimovic:
>> On 2021-09-23, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
>>>> On Wed, 22 Sep 2021 16:40:31 +0200
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>>>>
>>>>>>> to wherever there are these yield points. (The more yield points there
>>>>>>> are in your "coroutine", the more conditional gotos are required.)
>>>>>
>>>>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>>>>
>>>>> There is no easy solution. Have you considered the altetrnative
>>>>> of writing your own state-machine ? That's much worse.
>>>>
>>>> I find state machines very clear and easy to follow as well as being explicit
>>>> rather than having some stack in an unknown (from the programmers POV) state.
>>>
>>> No, that's much less clearer than having a state like you're in a normal
>>> function.
>> coroutines are just same thing as threads ...
>
> No, they're similar to fiberes - with much less overhead.


-- 
Evil Sinner!

[toc] | [prev] | [next] | [standalone]

#81452

On Thu, 23 Sep 2021 05:38:54 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
>> On Wed, 22 Sep 2021 16:40:31 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>>
>>>>> to wherever there are these yield points. (The more yield points there
>>>>> are in your "coroutine", the more conditional gotos are required.)
>>>
>>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>>
>>> There is no easy solution. Have you considered the altetrnative
>>> of writing your own state-machine ? That's much worse.
>> 
>> I find state machines very clear and easy to follow as well as being explicit
>
>> rather than having some stack in an unknown (from the programmers POV) state.
>
>
>No, that's much less clearer than having a state like you're in a normal
>function.

That is a matter of opinion.

[toc] | [prev] | [next] | [standalone]

#81519

Am 23.09.2021 um 11:11 schrieb HorseyWorsey@the_stables.com:
> On Thu, 23 Sep 2021 05:38:54 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
>>> On Wed, 22 Sep 2021 16:40:31 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>>>
>>>>>> to wherever there are these yield points. (The more yield points there
>>>>>> are in your "coroutine", the more conditional gotos are required.)
>>>>
>>>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>>>
>>>> There is no easy solution. Have you considered the altetrnative
>>>> of writing your own state-machine ? That's much worse.
>>>
>>> I find state machines very clear and easy to follow as well as being explicit
>>
>>> rather than having some stack in an unknown (from the programmers POV) state.
>>
>>
>> No, that's much less clearer than having a state like you're in a normal
>> function.
> 
> That is a matter of opinion.

That's not a matter of opinion. If you've managed to write a complex
sate-machine you honor the convenience and readability of coroutines.

[toc] | [prev] | [next] | [standalone]

#81534

On Fri, 24 Sep 2021 18:17:02 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.09.2021 um 11:11 schrieb HorseyWorsey@the_stables.com:
>> On Thu, 23 Sep 2021 05:38:54 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
>>>> On Wed, 22 Sep 2021 16:40:31 +0200
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>>>>
>>>>>>> to wherever there are these yield points. (The more yield points there
>>>>>>> are in your "coroutine", the more conditional gotos are required.)
>>>>>
>>>>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>>>>
>>>>> There is no easy solution. Have you considered the altetrnative
>>>>> of writing your own state-machine ? That's much worse.
>>>>
>>>> I find state machines very clear and easy to follow as well as being
>explicit
>>>
>>>> rather than having some stack in an unknown (from the programmers POV)
>state.
>>>
>>>
>>> No, that's much less clearer than having a state like you're in a normal
>>> function.
>> 
>> That is a matter of opinion.
>
>That's not a matter of opinion. If you've managed to write a complex
>sate-machine you honor the convenience and readability of coroutines.

No sane person would use coroutines instead of a nice clear state machine.
How the fuck are you supposed to debug a coredump from something that uses
coroutines? You have absolutely no idea what state its in until you step
through to the call itself or feel like reading a stack dump! With a state 
machine you just dump the state variable(s). Even the cppreference example
code for coroutines is an alphabet soup whereas normally their examples are
pretty clear.

This garbage paradigm should never have been included in C++ but it would seem
MS have the committee in its pocket.

[toc] | [prev] | [next] | [standalone]

#81538

Am 25.09.2021 um 11:19 schrieb HorseyWorsey@the_stables.com:
> On Fri, 24 Sep 2021 18:17:02 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 23.09.2021 um 11:11 schrieb HorseyWorsey@the_stables.com:
>>> On Thu, 23 Sep 2021 05:38:54 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 22.09.2021 um 17:01 schrieb HorseyWorsey@the_stables.com:
>>>>> On Wed, 22 Sep 2021 16:40:31 +0200
>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> Am 22.09.2021 um 11:26 schrieb HorseyWorsey@the_stables.com:
>>>>>>
>>>>>>>> to wherever there are these yield points. (The more yield points there
>>>>>>>> are in your "coroutine", the more conditional gotos are required.)
>>>>>>
>>>>>>> Having multiple yield points sounds like asking for sphagetti code. ...
>>>>>>
>>>>>> There is no easy solution. Have you considered the altetrnative
>>>>>> of writing your own state-machine ? That's much worse.
>>>>>
>>>>> I find state machines very clear and easy to follow as well as being
>> explicit
>>>>
>>>>> rather than having some stack in an unknown (from the programmers POV)
>> state.
>>>>
>>>>
>>>> No, that's much less clearer than having a state like you're in a normal
>>>> function.
>>>
>>> That is a matter of opinion.
>>
>> That's not a matter of opinion. If you've managed to write a complex
>> sate-machine you honor the convenience and readability of coroutines.
> 
> No sane person would use coroutines instead of a nice clear state machine.

State-machines are never clear ! You've to write a
	while( state != END )
		switch( state )
		{
		case STATE_A:
			...
			break;
		case STATE_B:
			...
			break;
		case STATE_C:
			...
			break;
		}
-loop and that's _much_ less readable.

> How the fuck are you supposed to debug a coredump from something that uses
> coroutines? ...

The coroutine-frame is a block of memory of the promise.
It should be debuggable.

[toc] | [prev] | [next] | [standalone]

#81540

On Sat, 25 Sep 2021 12:00:10 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.09.2021 um 11:19 schrieb HorseyWorsey@the_stables.com:
>> No sane person would use coroutines instead of a nice clear state machine.
>
>State-machines are never clear ! You've to write a
>	while( state != END )
>		switch( state )
>		{
>		case STATE_A:
>			...
>			break;
>		case STATE_B:
>			...
>			break;
>		case STATE_C:
>			...
>			break;
>		}
>-loop and that's _much_ less readable.

I do hope you're joking.

>> How the fuck are you supposed to debug a coredump from something that uses
>> coroutines? ...
>
>The coroutine-frame is a block of memory of the promise.
>It should be debuggable.

Oh please, don't make me laugh.

[toc] | [prev] | [next] | [standalone]

#81542

Am 25.09.2021 um 12:09 schrieb HorseyWorsey@the_stables.com:

>> Am 25.09.2021 um 11:19 schrieb HorseyWorsey@the_stables.com:
>>> No sane person would use coroutines instead of a nice clear state machine.
>>
>> State-machines are never clear ! You've to write a
>> 	while( state != END )
>> 		switch( state )
>> 		{
>> 		case STATE_A:
>> 			...
>> 			break;
>> 		case STATE_B:
>> 			...
>> 			break;
>> 		case STATE_C:
>> 			...
>> 			break;
>> 		}
>> -loop and that's _much_ less readable.

With C++-coroutines you have the control-flow of a normal func-
tion between the states. That's much more readable than the above
spaghetti-code. That's while fibers have been invented, but their
overhead is much larger and they're not integrated in the langauage
and thereby not so convenient.

[toc] | [prev] | [next] | [standalone]

#81543

On Sat, 25 Sep 2021 12:18:09 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.09.2021 um 12:09 schrieb HorseyWorsey@the_stables.com:
>
>>> Am 25.09.2021 um 11:19 schrieb HorseyWorsey@the_stables.com:
>>>> No sane person would use coroutines instead of a nice clear state machine.
>>>
>>> State-machines are never clear ! You've to write a
>>> 	while( state != END )
>>> 		switch( state )
>>> 		{
>>> 		case STATE_A:
>>> 			...
>>> 			break;
>>> 		case STATE_B:
>>> 			...
>>> 			break;
>>> 		case STATE_C:
>>> 			...
>>> 			break;
>>> 		}
>>> -loop and that's _much_ less readable.
>
>With C++-coroutines you have the control-flow of a normal func-
>tion between the states. That's much more readable than the above
>spaghetti-code.

Bollocks. Coroutines are the equivalent of a load of hidden static function
variables that will be very difficult to interrogate during debugging. But
then you seem to think the sun shines out of Microsofts backside and everything
they come up with is amazing.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web