• "C++20 Coroutines" by Martin Bond

    From Lynn McGuire@21:1/5 to All on Mon Sep 20 16:30:19 2021
    "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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bo Persson@21:1/5 to Lynn McGuire on Tue Sep 21 09:28:10 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Tue Sep 21 11:45:21 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Tue Sep 21 15:37:55 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Tue Sep 21 17:40:12 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to HorseyWorsey@the_stables.com on Wed Sep 22 05:22:59 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Juha Nieminen on Wed Sep 22 09:26:06 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alf P. Steinbach@21:1/5 to Juha Nieminen on Wed Sep 22 11:31:59 2021
    On 22 Sep 2021 07:22, Juha Nieminen wrote:
    Coroutines are compared to cooperative multitasking

    This is fast becoming the adopted terminology, but really it should be

    Continuations are compared to coroutines


    - Alf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Wed Sep 22 16:40:31 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Wed Sep 22 15:01:52 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam@21:1/5 to HorseyWorsey@the_stables.com on Wed Sep 22 18:43:35 2021
    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.

    HorseyWorsey@the_stables.com writes:

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

    I was about to make this exact comment. You saved me the trouble of doing
    that.

    Microsoft hijacked the standardization process in order to get co-routines
    into C++. std::threads' poor performance on MS-Windows has been documented,
    due to underlying OS design and/or limitations. This was MS's way of
    attempting to implement an alternative fake-multithreading that doesn't suck
    on their platform.


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEMWrVnbBKLOeG9ifkazpiviedvyUFAmFLsZcACgkQazpivied vyXpjhAA6KzqqGNi2SDztbFEYp+pc/GzCaezeyGdtFQ0lS/CsBxSyTFJ+XesUfKl QwnjgNVKXfWed5I/N51OWQLu3P+C+Ekk8fYTAZoQAxmG7WAhFgFNEVBxQrzd1M1m vWPuFAUL/7NxXPM67r/DXJbE5SeI7JyKTPUr2Vzk+ZcJ+lGbI+9b1J8qInlwqUuk OgkjujHPffTW4f+lrVS7OoHpXSPunfebuTTJZGJu/qS8RCaZ41K0vbUXxSaQyDgq jlC64jSxzmQbBFI3cYFOso+wpF2aCzdgMP+IX73jHoIzoSQ1Ou/rixO0tej12u0p JdMlZq3Rfyc/bjcaXTzPVNsMddEMlV5hKYgVAC2EUNsGjH7KCFiawrLSlDYcWb95 ERF2pR9lDyZAZkRCyjHc3KlbLfbUF9cJJDRFfpSdF+zw7YIGgTXEvdx6blHdlZMV DTM+dK8xXiWcnk4dIbvEcbkBQ7XM4A4qryczqF+12fuJJDgnf6un0OvBsFDQD9dH /nGTtE6AzNIUi1zp10H6+xM00iTavt8l6PGaVRKIqndT26p9VThGEmSP2/ReaELA RAGY9tUaRQQqvIJ99u/13WWBlFd5+pT8cJmFRcMm7yRtfIrGn8B+nfZWO69XDUKe yp+zaCpqD0/9nzAuEZUYazBVS/8Swohm7qX8kx2MN1tARGNSQG8=
    =QnPK
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Thu Sep 23 05:38:54 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to HorseyWorsey@the_stables.com on Thu Sep 23 07:42:22 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to Sam on Thu Sep 23 07:45:23 2021
    Sam <sam@email-scan.com> wrote:
    Microsoft hijacked the standardization process in order to get co-routines into C++. std::threads' poor performance on MS-Windows has been documented, due to underlying OS design and/or limitations. This was MS's way of attempting to implement an alternative fake-multithreading that doesn't suck on their platform.

    You seem to have a strange misconception that coroutines are nothing
    but simulating multithreading in a single-threaded program.

    They are aren't.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Bonita Montero on Thu Sep 23 09:05:19 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris M. Thomasson@21:1/5 to Juha Nieminen on Thu Sep 23 01:53:53 2021
    On 9/23/2021 12:45 AM, Juha Nieminen wrote:
    Sam <sam@email-scan.com> wrote:
    Microsoft hijacked the standardization process in order to get co-routines >> into C++. std::threads' poor performance on MS-Windows has been documented, >> due to underlying OS design and/or limitations. This was MS's way of
    attempting to implement an alternative fake-multithreading that doesn't suck >> on their platform.

    You seem to have a strange misconception that coroutines are nothing
    but simulating multithreading in a single-threaded program.

    They are aren't.


    Jeeze... This makes me think of the time I was using fibers in windows.
    Iirc, it was for sorting things. Also, iirc, it was broken down into,
    multiple fibers on a single thread. Multiple threads per process, then
    multiple processes. This was so long ago its making my head itch. Back
    on WinNT 4.0.

    I had to use them in Linux as well. Iirc, setcontext comes to mind. ;^)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Thu Sep 23 09:11:10 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Juha Nieminen on Thu Sep 23 09:14:50 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to HorseyWorsey@the_stables.com on Fri Sep 24 04:42:09 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Fri Sep 24 18:17:02 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Fri Sep 24 18:15:51 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Fri Sep 24 18:19:16 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Bonita Montero on Fri Sep 24 21:07:29 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam@21:1/5 to Juha Nieminen on Fri Sep 24 19:21:10 2021
    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.

    Juha Nieminen writes:

    Sam <sam@email-scan.com> wrote:
    Microsoft hijacked the standardization process in order to get co-routines into C++. std::threads' poor performance on MS-Windows has been documented, due to underlying OS design and/or limitations. This was MS's way of attempting to implement an alternative fake-multithreading that doesn't
    suck
    on their platform.

    You seem to have a strange misconception that coroutines are nothing
    but simulating multithreading in a single-threaded program.

    They are aren't.

    And I never said they are. They are not a simulation of multithreading.
    They're a failed simulation of multithreading, on a platform with a rather
    bad native implementation of multiple execution threads.


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEMWrVnbBKLOeG9ifkazpiviedvyUFAmFOXWYACgkQazpivied vyXGDhAA39/fCsD4dxiHADpEx3lJrb1gzbHj1xqisQNqMsRyT12Lbu81glvvZmpy K4kg0TSDWFboQKv+DUynMxUad7kgFu25mxYlHkzN5FJSBDQEhqOcaxcY1jxDfn/3 xB8O1MX3GhRvBT0QnhWKy3QNfZPBSP0rqIg+K45obL49c6munFMoQOoKsZMksSGd L1QJSfDJn8L9YlWF8SogtEl2570Hqg3DhPERtKoCLnW7lSx+qsekheqi/XXq5eh1 c0mEhfI+69DeUOKOhtf3UeY92idNf7l5QrsbmMJdAc4ry7H/6/kZRiqDvv329N0K aBkPBT/YtZALrl76K/swgy3EuXKS9I0VLBN9AFDk/1rTbV6hT/9Wu4wmuhPgY9aB qQF/cTTQuEfKTZQeG/0zCmeWMEETbFMOeYW+IYb7377+ApzfLEcPPDJsyihNrFIe 19oPzuoGEWTJmGrUnkzvWQEkoSwXiCH8Y5hLB7dhARqAU+tEeqqkE2Be5t2KuD7m BOHkaOnq/yY/bBG3Xmf3NsJ3FQsTTK0zvJe1v+r5ZGUkfusBHH9M33WH1deityeT BPRg3fOg3JoNDAmcXLnjnPVDxtM3109S2UcHJ3JDEFoqD3HJHatPAwsxRICNj+rs E1VhXmy8WUTyHhZWJUVTf9HPurfzWTgcxlNZ8y1aYyJsyX1Hwjg=
    =eYLO
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Bonita Montero on Sat Sep 25 00:57:26 2021
    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
  • From Branimir Maksimovic@21:1/5 to Bonita Montero on Sat Sep 25 00:58:52 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Sam on Sat Sep 25 09:28:45 2021
    On Fri, 24 Sep 2021 19:21:10 -0400
    Sam <sam@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-165744-1632525670-0001
    Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" >Content-Disposition: inline
    Content-Transfer-Encoding: 7bit

    Juha Nieminen writes:

    Sam <sam@email-scan.com> wrote:
    Microsoft hijacked the standardization process in order to get co-routines >> > into C++. std::threads' poor performance on MS-Windows has been documented,

    due to underlying OS design and/or limitations. This was MS's way of
    attempting to implement an alternative fake-multithreading that doesn't
    suck
    on their platform.

    You seem to have a strange misconception that coroutines are nothing
    but simulating multithreading in a single-threaded program.

    They are aren't.

    And I never said they are. They are not a simulation of multithreading. >They're a failed simulation of multithreading, on a platform with a rather >bad native implementation of multiple execution threads.

    And a diabolical implementation of process spawning.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sat Sep 25 09:19:57 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Sep 25 12:00:10 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sat Sep 25 10:09:56 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sat Sep 25 09:20:26 2021
    On Fri, 24 Sep 2021 18:19:16 +0200
    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.

    LMFAO!!!!!!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Sep 25 12:18:09 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Sep 25 12:42:10 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sat Sep 25 10:39:03 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sat Sep 25 10:44:18 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Sep 25 13:14:40 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to HorseyWorsey@the_stables.com on Sat Sep 25 12:32:31 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alf P. Steinbach@21:1/5 to Lynn McGuire on Sat Sep 25 15:14:43 2021
    On 20 Sep 2021 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."

    The main confusion about C++20 “coroutines” is that they're general coroutines.

    They're not: they're simple continuations, the special case of
    /stackless/ coroutines (no dedicated stack for each coroutine).

    While that's nice performance-wise it's very limited, and the Microsoft
    style support framework adopted in C++20 requires you to build a full
    fledged star ship in order to lift a little pebble; it's, well, moronic.

    ---

    I once started coding up real coroutines in terms of standard C++ threads.

    That could be very useful, in contrast to the mostly useless C++17 continuations.

    However, I stopped fiddling with it when the complexity of the
    implementation overwhelmed me. No doubt because of a lack of experience
    in safe multi-tasking. It would be really nice if SOMEONE could do this:
    real general coroutines, by leveraging real C++ threads.

    ---

    That could open the world of safe multi-tasking to C++ programmers in
    general.

    Another such enabler: an implementation of Ada-like rendezvous.

    And, and, ... Occam-like channels, maybe. :)


    - Alf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Bonita Montero on Sat Sep 25 12:44:05 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to HorseyWorsey@the_stables.com on Sat Sep 25 12:38:07 2021
    On 2021-09-25, HorseyWorsey@the_stables.com <HorseyWorsey@the_stables.com> wrote:

    And a diabolical implementation of process spawning.

    Well if done properly it's just preemptive shceduler
    that can schedule on single or multiple cores/cpus



    --
    7-77-777
    Evil Sinner!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Sep 25 15:58:16 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Bonita Montero on Sat Sep 25 13:59:56 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Sep 25 16:23:05 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sat Sep 25 15:04:42 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sat Sep 25 15:28:54 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Sep 25 18:44:55 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to Alf P. Steinbach on Sat Sep 25 23:07:58 2021
    On 9/25/2021 3:14 PM, Alf P. Steinbach wrote:
    On 20 Sep 2021 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."

    The main confusion about C++20 “coroutines” is that they're general coroutines.

    They're not: they're simple continuations, the special case of
    /stackless/ coroutines (no dedicated stack for each coroutine).

    While that's nice performance-wise it's very limited, and the Microsoft
    style support framework adopted in C++20 requires you to build a full
    fledged star ship in order to lift a little pebble; it's, well, moronic.

    ---

    I once started coding up real coroutines in terms of standard C++ threads.

    That could be very useful, in contrast to the mostly useless C++17 continuations.

    However, I stopped fiddling with it when the complexity of the
    implementation overwhelmed me. No doubt because of a lack of experience
    in safe multi-tasking. It would be really nice if SOMEONE could do this:
    real general coroutines, by leveraging real C++ threads.

    ---

    That could open the world of safe multi-tasking to C++ programmers in general.

    I'm no expert in coroutines, but AFAIU their main advantage is to enable multitasking without the overhead of multithreading.
    In order to achieve this, language support is needed that was just not available prior to C++20 (and even with C++20 such support is limited,
    so that only the subset of continuations is actually available, as you say)

    The point being, if you try to do that using threads kind of defeats the purpose, doesn't it?
    (even if you build this with full synchronization inside, you'll still
    pay the price of performance and resource usage, which can be relevant
    for this kind of thing)


    Another such enabler: an implementation of Ada-like rendezvous.

    And, and, ... Occam-like channels, maybe. :)


    - Alf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alf P. Steinbach@21:1/5 to Manfred on Sun Sep 26 01:50:00 2021
    On 25 Sep 2021 23:07, Manfred wrote:
    On 9/25/2021 3:14 PM, Alf P. Steinbach wrote:
    On 20 Sep 2021 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."

    The main confusion about C++20 “coroutines” is that they're general
    coroutines.

    They're not: they're simple continuations, the special case of
    /stackless/ coroutines (no dedicated stack for each coroutine).

    While that's nice performance-wise it's very limited, and the
    Microsoft style support framework adopted in C++20 requires you to
    build a full fledged star ship in order to lift a little pebble; it's,
    well, moronic.

    ---

    I once started coding up real coroutines in terms of standard C++
    threads.

    That could be very useful, in contrast to the mostly useless C++17
    continuations.

    However, I stopped fiddling with it when the complexity of the
    implementation overwhelmed me. No doubt because of a lack of
    experience in safe multi-tasking. It would be really nice if SOMEONE
    could do this: real general coroutines, by leveraging real C++ threads.

    ---

    That could open the world of safe multi-tasking to C++ programmers in
    general.

    I'm no expert in coroutines, but AFAIU their main advantage is to enable multitasking without the overhead of multithreading.

    What you write is an advantage of continuations compared to general
    coroutines. I consider that a very marginal advantage. Correctness is
    far, far more important than some micro-efficiency.

    The advantage of general coroutines is that they enable multi-tasking
    (namely cooperative multi-tasking) without the severe synchronization
    problems of general threads or processes.

    Coroutines don't automagically deal with all kinds of multi-tasking
    problems, in particular deadlocks are still possible, but you don't have
    two or more threads possibly accessing the same thing at a time, since
    only one coroutine executes at a time.


    In order to achieve this, language support is needed that was just not available prior to C++20 (and even with C++20 such support is limited,
    so that only the subset of continuations is actually available, as you say)

    True, but I fail to see any reason, and I haven't yet seen anybody able
    to cough up a reason, to have continuations in C++.


    The point being, if you try to do that using threads kind of defeats the purpose, doesn't it?

    No (you misunderstood the purpose).

    Doing this could open the world of safe multi-tasking to C++ programmers
    in general.

    Oh, I already wrote that, sorry.


    (even if you build this with full synchronization inside, you'll still
    pay the price of performance and resource usage, which can be relevant
    for this kind of thing)

    Yes, it must be built with synchronization inside, and like threads each general coroutine needs its own stack, which is another cost: firing up
    a general coroutine generally involves a dynamic allocation (though I
    guess with language support it's technically possible to use statically allocated stack areas when the number of coroutines has a reasonably low
    upper bound, but such support would be needed for that because standard
    threads don't provide any means to influence the per-thread stacks).


    Another such enabler: an implementation of Ada-like rendezvous.

    And, and, ... Occam-like channels, maybe. :)

    I forgot to mention Linda.

    Oh well.


    - Alf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Bonita Montero on Sun Sep 26 14:15:43 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to Alf P. Steinbach on Sun Sep 26 19:12:16 2021
    On 9/26/2021 1:50 AM, Alf P. Steinbach wrote:
    On 25 Sep 2021 23:07, Manfred wrote:
    On 9/25/2021 3:14 PM, Alf P. Steinbach wrote:
    On 20 Sep 2021 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."

    The main confusion about C++20 “coroutines” is that they're general
    coroutines.

    They're not: they're simple continuations, the special case of
    /stackless/ coroutines (no dedicated stack for each coroutine).

    While that's nice performance-wise it's very limited, and the
    Microsoft style support framework adopted in C++20 requires you to
    build a full fledged star ship in order to lift a little pebble;
    it's, well, moronic.

    ---

    I once started coding up real coroutines in terms of standard C++
    threads.

    That could be very useful, in contrast to the mostly useless C++17
    continuations.

    However, I stopped fiddling with it when the complexity of the
    implementation overwhelmed me. No doubt because of a lack of
    experience in safe multi-tasking. It would be really nice if SOMEONE
    could do this: real general coroutines, by leveraging real C++ threads.

    ---

    That could open the world of safe multi-tasking to C++ programmers in
    general.

    I'm no expert in coroutines, but AFAIU their main advantage is to
    enable multitasking without the overhead of multithreading.

    What you write is an advantage of continuations compared to general coroutines. I consider that a very marginal advantage. Correctness is
    far, far more important than some micro-efficiency.

    Correctness is the precondition, obviously, but this is not about micro-efficiency (see below)


    The advantage of general coroutines is that they enable multi-tasking
    (namely cooperative multi-tasking) without the severe synchronization problems of general threads or processes.

    Yes, what you call "severe synchronization problems" is part of what I
    called "overhead". (I tend to write in a very concise way - that is
    meant both as "coding overhead" and "resource usage overhead")


    Coroutines don't automagically deal with all kinds of multi-tasking
    problems, in particular deadlocks are still possible, but you don't have
    two or more threads possibly accessing the same thing at a time, since
    only one coroutine executes at a time.

    Yes, that was clear.



    In order to achieve this, language support is needed that was just not
    available prior to C++20 (and even with C++20 such support is limited,
    so that only the subset of continuations is actually available, as you
    say)

    True, but I fail to see any reason, and I haven't yet seen anybody able
    to cough up a reason, to have continuations in C++.

    Aren't continuations in C++20? Do you mean general coroutines?
    If that is the case, the fact that POSIX has (had) support for them
    would suggest that it should be possible, then the fact that they
    dropped it may also suggest that there are counter indications of some
    sort, but I agree that still the question for explanation stands.



    The point being, if you try to do that using threads kind of defeats
    the purpose, doesn't it?

    No (you misunderstood the purpose).
    Not entirely (see above)


    Doing this could open the world of safe multi-tasking to C++ programmers
    in general.

    Oh, I already wrote that, sorry.
    So, you mean make life easier for C++ programmers that are not
    comfortable with multithreaded programming, fair enough. ("open the
    world" sounded to me like there would be something more involved).



    (even if you build this with full synchronization inside, you'll still
    pay the price of performance and resource usage, which can be relevant
    for this kind of thing)

    Yes, it must be built with synchronization inside, and like threads each general coroutine needs its own stack, which is another cost: firing up
    a general coroutine generally involves a dynamic allocation (though I
    guess with language support it's technically possible to use statically allocated stack areas when the number of coroutines has a reasonably low upper bound, but such support would be needed for that because standard threads don't provide any means to influence the per-thread stacks).

    Referring to the first "see below" above: there are multiple performance
    costs involved with firing up multiple threads - whether these costs
    fall into the category of "micro-efficiency" depends on the context.

    AFAIU coroutines are especially used (or at least advocated for) in
    areas like high-throughput server processes, real time systems, and architectures with strict resource constraints. This is why I wrote
    performance might be relevant for this kind of thing.

    As to how it works, with POSIX I found "man makecontext" interesting (on
    any decent Linux box or the appropriate POSIX documentation).
    But then, support for this has been removed in POSIX.1-2008, so probably
    it's not that pressing of a need.


    Another such enabler: an implementation of Ada-like rendezvous.

    And, and, ... Occam-like channels, maybe. :)

    I forgot to mention Linda.

    Oh well.


    - Alf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to Sam on Mon Sep 27 05:42:14 2021
    Sam <sam@email-scan.com> wrote:
    Sam <sam@email-scan.com> wrote:
    Microsoft hijacked the standardization process in order to get co-routines >> > into C++. std::threads' poor performance on MS-Windows has been documented,
    due to underlying OS design and/or limitations. This was MS's way of
    attempting to implement an alternative fake-multithreading that doesn't
    suck
    on their platform.

    You seem to have a strange misconception that coroutines are nothing
    but simulating multithreading in a single-threaded program.

    They are aren't.

    And I never said they are. They are not a simulation of multithreading. They're a failed simulation of multithreading, on a platform with a rather bad native implementation of multiple execution threads.

    My claim still stands. You did nothing to refute it. You seem to have this strange misconception that coroutines are only about simulating
    multithreading, and nothing else. Whether you think they are a good or
    a bad feature is completely irrelevant to this.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to Branimir Maksimovic on Mon Sep 27 05:39:34 2021
    Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
    State machines are spagetty if not OO. Think about it.

    Off-topic, but could you please stop top-posting? It's annoying.

    Just edit the original post, leaving the relevant part you are
    responding to, and write your response below. Like I'm doing here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Tue Sep 28 07:24:32 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Juha Nieminen on Wed Sep 29 02:30:03 2021
    On 2021-09-27, Juha Nieminen <nospam@thanks.invalid> wrote:
    Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
    State machines are spagetty if not OO. Think about it.

    Off-topic, but could you please stop top-posting? It's annoying.

    Just edit the original post, leaving the relevant part you are
    responding to, and write your response below. Like I'm doing here.
    I haven't mentioned that. Sure I can post normally, no problem,
    i just wanted to MAKE A POINT :P

    --

    7-77-777
    Evil Sinner!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Ben Bacarisse on Wed Oct 6 13:19:12 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)