Announcement

Collapse
No announcement yet.

GCC 11 Enables Co-Routines Support In C++20 Mode

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 11 Enables Co-Routines Support In C++20 Mode

    Phoronix: GCC 11 Enables Co-Routines Support In C++20 Mode

    The recently released GCC 10 compiler landed initial coroutines support for this major C++20 feature but wasn't enabled unless explicitly enabling that option...

    http://www.phoronix.com/scan.php?pag...PP20-Coroutine

  • #2
    I think C++ deserves a pat on the back for trying to catch up to Rust despite being held back by backwards compatibility and hence not being able to do things as elegantly as Rust does.

    Comment


    • #3
      Originally posted by cl333r View Post
      I think C++ deserves a pat on the back for trying to catch up to Rust despite being held back by backwards compatibility and hence not being able to do things as elegantly as Rust does.
      Without backward compatibility, your "New C++" is just another new language that resembles C.
      Microsoft tried this ~20 years ago, and named their two proposals as C# and C++/CLI.

      Comment


      • #4
        these new coroutines are extremely hard to use. Everyone who doesn’t believe welcome to try. I have no idea why it was not possible to provide stackfull coroutines python or java script style ?? However I know the current implementation in the standard was proposed by a guy from Microsoft.

        Comment


        • #5
          Originally posted by zxy_thf View Post
          Without backward compatibility, your "New C++" is just another new language that resembles C.
          Microsoft tried this ~20 years ago, and named their two proposals as C# and C++/CLI.
          IIRC, C# -- pronounced "Chash" (the first "h" is silent) -- was intended to be a better Java than Java. In many technical ways it succeeds; it's adoption being initially limited by tepid support for De Icaza's early open-source implementation -- Mono -- and later by lack of legacy applications to fuel it's future progress.

          C++/CLI attempts to implement a C++ work-alike - sort of - on the .NET framework. It's only sort of like C++ because .NET mandates garbage collection, so C++/CLI is sort-of like a garbage-collected C++.

          Sort of. Explicit developer-controlled memory management is a key underlying feature of C++. It is fast, efficient and predictable, but does have certain... drawbacks. But without them, as you observed, C++/CLI does suffer a distinct lack of backward compatibility.

          Comment


          • #6
            Originally posted by dev_null View Post
            these new coroutines are extremely hard to use. Everyone who doesn’t believe welcome to try. I have no idea why it was not possible to provide stackfull coroutines python or java script style ?? However I know the current implementation in the standard was proposed by a guy from Microsoft.
            The current implementation is the basic plumbing on which it is possible to build a library support. The intended use is not for the generic developer. You should look to a library like cppcoro https://github.com/lewissbaker/cppcoro which is a lot more user friendly :

            Code:
            using cppcoro;
            generator<const std::uint64_t> fibonacci() {
                std::uint64_t a = 0, b = 1;
                while (true) {
                     co_yield b;
                     auto tmp = a;
                     a = b;
                     b += tmp;
                }
            }
            void usage() {
                for (auto i : fibonacci()) {
                    if (i > 1'000'000)
                         break;
                    std::cout << i << std::endl;
                }
            }

            Comment


            • #7
              Well, I'm just glad that C++ is finally getting around to having modules and co-routines, like Modula-2 did over 35 years ago. Back then, and even now, the C/C++ attitude on separately compiled modules was always "we don't need no stinkin' modules, we have awesome 'include' files that get compiled over and over again for every source file".

              I'm kind of curious about what the motivation is for co-routines, though, since threads are better and fully supported. I did manage to write a terminal emulator with Modula-2 co-routines, way back when, where one routine managed the terminal screen and communications, and another ran a graphical task for displaying images. It wasn't pretty by modern standards, but it was pretty cool for a DOS program.

              Comment


              • #8
                Originally posted by Mark625 View Post
                I'm kind of curious about what the motivation is for co-routines, though, since threads are better and fully supported.
                I can only guess it is for tiny single processor embedded type systems.

                It could also be for certain algorithms that come out looking cool when done with generators and such. Although C++ could already do those, but a little bit messy, by tracking state in an object.

                Comment


                • #9
                  Originally posted by pipe13 View Post
                  C# -- pronounced "Chash" (the first "h" is silent)
                  Yep. Seems legit.

                  Comment


                  • #10
                    Originally posted by Mark625 View Post
                    Well, I'm just glad that C++ is finally getting around to having modules and co-routines, like Modula-2 did over 35 years ago. Back then, and even now, the C/C++ attitude on separately compiled modules was always "we don't need no stinkin' modules, we have awesome 'include' files that get compiled over and over again for every source file".

                    I'm kind of curious about what the motivation is for co-routines, though, since threads are better and fully supported. I did manage to write a terminal emulator with Modula-2 co-routines, way back when, where one routine managed the terminal screen and communications, and another ran a graphical task for displaying images. It wasn't pretty by modern standards, but it was pretty cool for a DOS program.
                    Threads are for doing a bunch of CPU-bound tasks at the same time (ie. working busily). Things like coroutines or async APIs are for doing a bunch of I/O-bound tasks at the same time (ie. waiting busily).

                    The overhead of storing per-thread state, as small as it is, quickly becomes prohibitive when you're waiting on tens or hundreds of thousands of connections.

                    Comment

                    Working...
                    X