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

"C++20 Coroutines" by Martin Bond

Started by	Lynn McGuire <lynnmcguire5@gmail.com>
First post	2021-09-20 16:30 -0500
Last post	2021-09-26 19:12 +0200
Articles	20 on this page of 55 — 12 participants

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

  "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 2 of 3 — ← Prev page 1 [2] 3 Next page →

#81544

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-09-25 12:42 +0200
Message-ID	<simue2$d23$1@dont-email.me>
In reply to	#81543

Am 25.09.2021 um 12:39 schrieb HorseyWorsey@the_stables.com:
> 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.

If you write state-machines on your own the state isn't kept on the
stack as well.

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

#81545

From	HorseyWorsey@the_stables.com
Date	2021-09-25 10:44 +0000
Message-ID	<simui2$10u6$1@gioia.aioe.org>
In reply to	#81544

On Sat, 25 Sep 2021 12:42:10 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.09.2021 um 12:39 schrieb HorseyWorsey@the_stables.com:
>> 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.
>
>If you write state-machines on your own the state isn't kept on the
>stack as well.

It doesn't matter where the state variable(s) are kept, the point is they're 
easily accessable and modifiable in a debugger.

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

#81547

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-09-25 13:14 +0200
Message-ID	<sin0b1$qmh$1@dont-email.me>
In reply to	#81545

Am 25.09.2021 um 12:44 schrieb HorseyWorsey@the_stables.com:
> On Sat, 25 Sep 2021 12:42:10 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 25.09.2021 um 12:39 schrieb HorseyWorsey@the_stables.com:
>>> 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.
>>
>> If you write state-machines on your own the state isn't kept on the
>> stack as well.
> 
> It doesn't matter where the state variable(s) are kept, the point is they're
> easily accessable and modifiable in a debugger.

That's part of your promise and can be inspected with a C++20-capable 
debugger.

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

#81554

From	Branimir Maksimovic <branimir.maksimovic@gmail.com>
Date	2021-09-25 12:44 +0000
Message-ID	<pQE3J.197876$T_8.174908@fx48.iad>
In reply to	#81547

On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
> That's part of your promise and can be inspected with a C++20-capable 
> debugger.
Which one?

-- 
7-77-777
Evil Sinner!

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

#81558

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-09-25 15:58 +0200
Message-ID	<sin9to$tuu$2@dont-email.me>
In reply to	#81554

Am 25.09.2021 um 14:44 schrieb Branimir Maksimovic:
> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>
>> That's part of your promise and can be inspected with a C++20-capable
>> debugger.
> Which one?

VS 2020 beta.

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

#81560

From	Branimir Maksimovic <branimir.maksimovic@gmail.com>
Date	2021-09-25 13:59 +0000
Message-ID	<wXF3J.131542$lC6.6223@fx41.iad>
In reply to	#81558

On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 25.09.2021 um 14:44 schrieb Branimir Maksimovic:
>> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>
>>> That's part of your promise and can be inspected with a C++20-capable
>>> debugger.
>> Which one?
>
> VS 2020 beta.

i am still on 2-17, didn't like 2-19. Let's try 2020 when I have time...
>


-- 
7-77-777
Evil Sinner!

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

#81562

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-09-25 16:23 +0200
Message-ID	<sinbc9$8rp$1@dont-email.me>
In reply to	#81560

Am 25.09.2021 um 15:59 schrieb Branimir Maksimovic:
> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 25.09.2021 um 14:44 schrieb Branimir Maksimovic:
>>> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>
>>>> That's part of your promise and can be inspected with a C++20-capable
>>>> debugger.
>>> Which one?
>>
>> VS 2020 beta.
> 
> i am still on 2-17, didn't like 2-19. Let's try 2020 when I have time...

I think sooner or later all C++IDEs will have the capabilility to debug
inspect the state inside the promise of a coroutine.

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

#81637

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-09-28 07:24 +0200
Message-ID	<siu8uh$2f7$1@dont-email.me>
In reply to	#81562

Am 25.09.2021 um 16:23 schrieb Bonita Montero:
> Am 25.09.2021 um 15:59 schrieb Branimir Maksimovic:
>> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 25.09.2021 um 14:44 schrieb Branimir Maksimovic:
>>>> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>
>>>>> That's part of your promise and can be inspected with a C++20-capable
>>>>> debugger.
>>>> Which one?
>>>
>>> VS 2020 beta.
>>
>> i am still on 2-17, didn't like 2-19. Let's try 2020 when I have time...
> 
> I think sooner or later all C++IDEs will have the capabilility to debug
> inspect the state inside the promise of a coroutine.

This feature is trivial to update because the variables of
a cououtine are simply a normal compiler-generated struct.

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

#81567

From	HorseyWorsey@the_stables.com
Date	2021-09-25 15:28 +0000
Message-ID	<sinf7m$4hb$1@gioia.aioe.org>
In reply to	#81558

On Sat, 25 Sep 2021 15:58:16 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.09.2021 um 14:44 schrieb Branimir Maksimovic:
>> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>
>>> That's part of your promise and can be inspected with a C++20-capable
>>> debugger.
>> Which one?
>
>VS 2020 beta.

Quelle surprise!

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

#81565

From	HorseyWorsey@the_stables.com
Date	2021-09-25 15:04 +0000
Message-ID	<sindqa$1gol$1@gioia.aioe.org>
In reply to	#81547

On Sat, 25 Sep 2021 13:14:40 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.09.2021 um 12:44 schrieb HorseyWorsey@the_stables.com:
>> On Sat, 25 Sep 2021 12:42:10 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 25.09.2021 um 12:39 schrieb HorseyWorsey@the_stables.com:
>>>> 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.
>>>
>>> If you write state-machines on your own the state isn't kept on the
>>> stack as well.
>> 
>> It doesn't matter where the state variable(s) are kept, the point is they're
>> easily accessable and modifiable in a debugger.
>
>That's part of your promise and can be inspected with a C++20-capable 
>debugger.

Oh very useful. So not only do you need a cutting edge debugger which might
not be available in all execution enviroments, you have to interrogate a 
compiler generated object too. So simple compared to state variables!

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

#81568

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-09-25 18:44 +0200
Message-ID	<sinjm6$6h6$1@dont-email.me>
In reply to	#81565

> Oh very useful. So not only do you need a cutting edge debugger which might
> not be available in all execution enviroments, you have to interrogate a
> compiler generated object too. So simple compared to state variables!

You can be assured that in the near future most C++-capable debuggers
will support that.

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

#81602

From	HorseyWorsey@the_stables.com
Date	2021-09-26 14:15 +0000
Message-ID	<sipvaf$71a$1@gioia.aioe.org>
In reply to	#81568

On Sat, 25 Sep 2021 18:44:55 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Oh very useful. So not only do you need a cutting edge debugger which might
>> not be available in all execution enviroments, you have to interrogate a
>> compiler generated object too. So simple compared to state variables!
>
>You can be assured that in the near future most C++-capable debuggers
>will support that.

In the real world as opposed to your toy home dev enviroment, compilers
and debuggers do not get updated very often because they have to be
thoroughly tested to make sure they don't break the code or cause some other
issue. Keeping a business running is more important than having the latest
bleeding edge language features.

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

#81550

From	Branimir Maksimovic <branimir.maksimovic@gmail.com>
Date	2021-09-25 12:32 +0000
Message-ID	<zFE3J.37356$rsCb.10883@fx01.iad>
In reply to	#81534

On 2021-09-25, HorseyWorsey@the_stables.com <HorseyWorsey@the_stables.com> wrote:
> On Fri, 24 Sep 2021 18:17:02 +0200
>
> 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.

Coroutines are nice for ones that debug in different ways.
Don't take tool because it is not appropropriate TO YOU.
it's selfish...
>


-- 
7-77-777
Evil Sinner!

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

#81443

From	Juha Nieminen <nospam@thanks.invalid>
Date	2021-09-23 07:42 +0000
Message-ID	<sihb4s$1s8m$1@gioia.aioe.org>
In reply to	#81406

HorseyWorsey@the_stables.com wrote:
> 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.

I don't understand what that has anything to do with what I wrote.

Classes don't remove the need to manually write them, with all the
variables necessary to retain state, as said.

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

No, yielding precisely *avoids* spaghetti code, because the complexity
is taken care by the compiler rather than explicitly by your code.
You won't have large switch blocks or chained ifs, with gotos or
function calls in each branch, nor separate classes or structs containing
the state of the function. Instead of all that, you have a single
'yield' at every location where you need to return to the caller. After
that the execution continues from there as if nothing had happened.

*Significantly* simpler.

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

So you think that a couple of 'yield' instructions here and there is
not any simpler than having to have some class or struct containing the
state of the decompresser, and some chained if, or a switch block, that
jumps wherever the processing was going on at that moment, based on those
state variables?

In that case, I don't know what to say.

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

#81453

From	HorseyWorsey@the_stables.com
Date	2021-09-23 09:14 +0000
Message-ID	<sihgia$cl8$1@gioia.aioe.org>
In reply to	#81443

On Thu, 23 Sep 2021 07:42:22 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>HorseyWorsey@the_stables.com wrote:
>> 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.
>
>I don't understand what that has anything to do with what I wrote.
>
>Classes don't remove the need to manually write them, with all the
>variables necessary to retain state, as said.

Where did I say they did? I'm saying the point of them is to black box state,
not that it doesn't require any effort to attain that.

>> Having multiple yield points sounds like asking for sphagetti code.
>
>No, yielding precisely *avoids* spaghetti code, because the complexity
>is taken care by the compiler rather than explicitly by your code.
>You won't have large switch blocks or chained ifs, with gotos or
>function calls in each branch, nor separate classes or structs containing
>the state of the function. Instead of all that, you have a single
>'yield' at every location where you need to return to the caller. After
>that the execution continues from there as if nothing had happened.

Oh sure, just do a co_call or co_resume, obvious where it'll go. Not. Its
a magical mystery tour of the code dependent on the stack. At least state
machines are explicit.

>*Significantly* simpler.

Syntatically maybe.

>> Hmm, not convinced thats any simpler than using object or global state.
>
>So you think that a couple of 'yield' instructions here and there is
>not any simpler than having to have some class or struct containing the
>state of the decompresser, and some chained if, or a switch block, that
>jumps wherever the processing was going on at that moment, based on those
>state variables?

Yes.

>In that case, I don't know what to say.

Good, say nothing. We'll just have to disagree.

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

#81500

From	Juha Nieminen <nospam@thanks.invalid>
Date	2021-09-24 04:42 +0000
Message-ID	<sijkuv$m21$3@gioia.aioe.org>
In reply to	#81453

HorseyWorsey@the_stables.com wrote:
>>So you think that a couple of 'yield' instructions here and there is
>>not any simpler than having to have some class or struct containing the
>>state of the decompresser, and some chained if, or a switch block, that
>>jumps wherever the processing was going on at that moment, based on those
>>state variables?
> 
> Yes.

Then I don't know what to say. Rather than perhaps question your sanity.

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

#81520

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-09-24 18:19 +0200
Message-ID	<siktq3$vpc$4@dont-email.me>
In reply to	#81443

Am 23.09.2021 um 09:42 schrieb Juha Nieminen:

> No, yielding precisely *avoids* spaghetti code, ...

State-machines are _always_ spahgetti-code (while( !end )
switch( state ) { ... }), even when you write them conventionally.
But coroutines  are _much_ more readable and maintainable.

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

#81526

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2021-09-24 21:07 +0100
Message-ID	<87zgs1yby6.fsf@bsb.me.uk>
In reply to	#81520

Bonita Montero <Bonita.Montero@gmail.com> writes:

> State-machines are _always_ spahgetti-code (while( !end )
> switch( state ) { ... }), even when you write them conventionally.

Obviously one person's spaghetti is another person's farfalle, but in my
opinion, if the state is a (a pointer to a) function that returns (a
pointer to) the next state, then you just get a clean loop calling a
function:

   data d = { ... };
   State state = initial;
   while (state) state = (State)state(&d);

C++ has trouble writing the recursive type, so you need a cast, but it's
a safe cast.

-- 
Ben.

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

#81883

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Date	2021-10-06 13:19 -0700
Message-ID	<865yu9rjnj.fsf@linuxsc.com>
In reply to	#81526

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> State-machines are _always_ spahgetti-code (while( !end )
>> switch( state ) { ... }), even when you write them conventionally.
>
> Obviously one person's spaghetti is another person's farfalle, but
> in my opinion, if the state is a (a pointer to a) function that
> returns (a pointer to) the next state, then you just get a clean
> loop calling a function:
>
>    data d = { ... };
>    State state = initial;
>    while (state) state = (State)state(&d);
>
> C++ has trouble writing the recursive type, so you need a cast, but
> its a safe cast.

In C++, needing a cast can be avoided by wrapping the function
pointer in a class or struct, as for example:

    class State {
        typedef State (*Go)( data & );
        Go go;

      public:
        State( Go g ) : go( g ) {}

        operator bool(){ return go; }

        State operator()( data &data ){
            return  go( data );
        }
    };


    void
    run_state_machine( State initial, data &data ){
        State s = initial;
        while(  s  )  s = s( data );
    }

The example above is specific to a partcular type of "data" being
acted on, but it's easy to generalize around that shortcoming by
using templates.

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

#81530

From	Branimir Maksimovic <branimir.maksimovic@gmail.com>
Date	2021-09-25 00:58 +0000
Message-ID	<gvu3J.74156$QzOf.56745@fx17.iad>
In reply to	#81520

State machines are spagetty if not OO. Think about it.

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

On 2021-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 23.09.2021 um 09:42 schrieb Juha Nieminen:
>
>> No, yielding precisely *avoids* spaghetti code, ...
>
> State-machines are _always_ spahgetti-code (while( !end )
> switch( state ) { ... }), even when you write them conventionally.
> But coroutines  are _much_ more readable and maintainable.
>


-- 
Evil Sinner!

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

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

"C++20 Coroutines" by Martin Bond

Contents

#81544

#81545

#81547

#81554

#81558

#81560

#81562

#81637

#81567

#81565

#81568

#81602

#81550

#81443

#81453

#81500

#81520

#81526

#81883

#81530