Announcement

Collapse
No announcement yet.

GCC Begins Preparing For C++20 With -std=c++2a

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

  • GCC Begins Preparing For C++20 With -std=c++2a

    Phoronix: GCC Begins Preparing For C++20 With -std=c++2a

    With C++20 feature talk heating up, GNU Compiler Collection (GCC) developers are beginning to prepare working on more of the new compiler functionality for this next standard due out in a few years...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Let's hope clang (or somebody else) implements concepts this time, so it concepts isn't once again removed from gcc's switch like it was from c++0x and c++1z.

    Comment


    • #3
      I can appreciate the C++ compiler developers are aggressively keeping up with drafts of future standards. And I appreciate that the C++ standards committee is improving/extending the language. But I don't appreciate that the C++ language has evolved from a stable language to a beta/draft language. In my opinion, these 2-3 year revision cycles are way too frequent for a language like C++. I think it should be more like 8-10 year update cycles (e.g. C++03 to C++11) so that the language upholds its reputation as a rock solid stable language and developers can master the new features without having to wonder about all these other draft features. They also have to think less about compiler support headaches. Now-a-days, I find myself checking if VS20## supports C++## feature since I try to write code compatible with lots of compilers across Linux and Windows.

      In graduate school, I had a friend using some C++0x draft features for his research and I think some of those changes were revised, removed or changed and that really bit him one or two times. That was C++03 to C++11! Now we have C++11 to C++14, C++14 to C++17, C++17 to C++20. Compilers are implementing the draft features as soon as they're proposed and some developers and projects are early adopters. The draft features can and do proliferate in the open source scene and wreak havoc by being revised, changed, or removed and inconsistent compiler support across all the different operating systems can cause all sorts of burdens on end users and developers.

      In my opinion. It's too much. If this is the new norm for C++, it may very well harm C++'s reputation as a powerful, solid and stable language. The reputation will become: bleeding edge risky language with inconsistent compiler support. I can even imagine hideous preprocessors checking compiler versions to ensure certain features even work or work correctly (for developers considerate of their users anyway).

      Comment


      • #4
        Originally posted by nslay View Post
        I can appreciate the C++ compiler developers are aggressively keeping up with drafts of future standards. And I appreciate that the C++ standards committee is improving/extending the language. But I don't appreciate that the C++ language has evolved from a stable language to a beta/draft language. In my opinion, these 2-3 year revision cycles are way too frequent for a language like C++. I think it should be more like 8-10 year update cycles (e.g. C++03 to C++11) so that the language upholds its reputation as a rock solid stable language and developers can master the new features without having to wonder about all these other draft features. They also have to think less about compiler support headaches. Now-a-days, I find myself checking if VS20## supports C++## feature since I try to write code compatible with lots of compilers across Linux and Windows.

        In graduate school, I had a friend using some C++0x draft features for his research and I think some of those changes were revised, removed or changed and that really bit him one or two times. That was C++03 to C++11! Now we have C++11 to C++14, C++14 to C++17, C++17 to C++20. Compilers are implementing the draft features as soon as they're proposed and some developers and projects are early adopters. The draft features can and do proliferate in the open source scene and wreak havoc by being revised, changed, or removed and inconsistent compiler support across all the different operating systems can cause all sorts of burdens on end users and developers.

        In my opinion. It's too much. If this is the new norm for C++, it may very well harm C++'s reputation as a powerful, solid and stable language. The reputation will become: bleeding edge risky language with inconsistent compiler support. I can even imagine hideous preprocessors checking compiler versions to ensure certain features even work or work correctly (for developers considerate of their users anyway).
        Well, you can always wait a bit before using the newest features. Let the compilers implement them. E.g. avoid anything higher than C++14 for now.

        Comment


        • #5
          Originally posted by nslay View Post
          In my opinion. It's too much. If this is the new norm for C++, it may very well harm C++'s reputation as a powerful, solid and stable language. The reputation will become: bleeding edge risky language with inconsistent compiler support. I can even imagine hideous preprocessors checking compiler versions to ensure certain features even work or work correctly (for developers considerate of their users anyway).
          As much as I'm likely to regret it, I've got a "looking at a trainwreck" desire to see how people with a foam-at-the-mouth irrational antagonism toward Rust would react to this.

          Comment


          • #6
            Originally posted by nslay View Post
            In graduate school, I had a friend using some C++0x draft features for his research and I think some of those changes were revised, removed or changed and that really bit him one or two times.
            No offense, but did "draft" lose its "use it at your own risk" meaning lately?

            In my opinion. It's too much.
            Yeah, let's turn C++ into COBOL because people manning big projects can't simply show they have a brain and target a stable feature level with their code.

            That's communism, sheer communism I say.

            Comment


            • #7
              Originally posted by nslay View Post
              I can appreciate the C++ compiler developers are aggressively keeping up with drafts of future standards. And I appreciate that the C++ standards committee is improving/extending the language. But I don't appreciate that the C++ language has evolved from a stable language to a beta/draft language. In my opinion, these 2-3 year revision cycles are way too frequent for a language like C++. I think it should be more like 8-10 year update cycles (e.g. C++03 to C++11) so that the language upholds its reputation as a rock solid stable language and developers can master the new features without having to wonder about all these other draft features. They also have to think less about compiler support headaches. Now-a-days, I find myself checking if VS20## supports C++## feature since I try to write code compatible with lots of compilers across Linux and Windows.

              In graduate school, I had a friend using some C++0x draft features for his research and I think some of those changes were revised, removed or changed and that really bit him one or two times. That was C++03 to C++11! Now we have C++11 to C++14, C++14 to C++17, C++17 to C++20. Compilers are implementing the draft features as soon as they're proposed and some developers and projects are early adopters. The draft features can and do proliferate in the open source scene and wreak havoc by being revised, changed, or removed and inconsistent compiler support across all the different operating systems can cause all sorts of burdens on end users and developers.

              In my opinion. It's too much. If this is the new norm for C++, it may very well harm C++'s reputation as a powerful, solid and stable language. The reputation will become: bleeding edge risky language with inconsistent compiler support. I can even imagine hideous preprocessors checking compiler versions to ensure certain features even work or work correctly (for developers considerate of their users anyway).
              The standard changes have to implemented by two compilers before they can move out of draft phase. Draft here just means they have only been proven to be correct and doable theoretically, not in practice.

              Comment


              • #8
                Originally posted by nslay View Post
                I can appreciate the C++ compiler developers are aggressively keeping up with drafts of future standards. And I appreciate that the C++ standards committee is improving/extending the language. But I don't appreciate that the C++ language has evolved from a stable language to a beta/draft language. In my opinion, these 2-3 year revision cycles are way too frequent for a language like C++. I think it should be more like 8-10 year update cycles (e.g. C++03 to C++11) so that the language upholds its reputation as a rock solid stable language and developers can master the new features without having to wonder about all these other draft features. They also have to think less about compiler support headaches. Now-a-days, I find myself checking if VS20## supports C++## feature since I try to write code compatible with lots of compilers across Linux and Windows.

                In graduate school, I had a friend using some C++0x draft features for his research and I think some of those changes were revised, removed or changed and that really bit him one or two times. That was C++03 to C++11! Now we have C++11 to C++14, C++14 to C++17, C++17 to C++20. Compilers are implementing the draft features as soon as they're proposed and some developers and projects are early adopters. The draft features can and do proliferate in the open source scene and wreak havoc by being revised, changed, or removed and inconsistent compiler support across all the different operating systems can cause all sorts of burdens on end users and developers.

                In my opinion. It's too much. If this is the new norm for C++, it may very well harm C++'s reputation as a powerful, solid and stable language. The reputation will become: bleeding edge risky language with inconsistent compiler support. I can even imagine hideous preprocessors checking compiler versions to ensure certain features even work or work correctly (for developers considerate of their users anyway).
                Sorry, but for me its not moving fast enough. How would you expect the planned features to be tested, nothing beats feedback from developers. I was adopting C++11 features early, while gcc still had severe trouble with them - that was after the formal release (gcc 4.7 and 4.8). It took time for anything to become fixed, I would like to think my bug-reports helped. clang helped also, because it had alot more semantic tests and shown me bugs (invalid C++) in my code which gcc silently accepted and messed up.

                If anything then the features should be tested ASAP, both semantically (standardese) and implementations. That way you don`t have to guard for C++ version and compiler version like it was with C++11 (We got away by simply not supporting gcc < 4.9 anymore).

                In a way, you as C++ developer should take the chance at making the official release versions stable by testing the draft versions. The standards-body is rather small and can use the help. If you don`t then fine, but don`t complain about buggy releases.

                And I don`t want to remember the time before C++11, horrible hacks for pretty much every compiler and the lack of useful features like alignas or __has_include that meant preprocessor magic for all those quite-similar-but-not extensions and libraries.

                I would actually love a way to add library-extensions backwards, say use C++17 std::size in C++11. Its does not need any C++17/C++14 language features.

                Comment


                • #9
                  Meh, why was my long post "unapproved"? Never had a problem posting
                  Seems its gone now =(

                  Comment


                  • #10
                    Originally posted by discordian View Post
                    Meh, why was my long post "unapproved"? Never had a problem posting
                    Seems its gone now =(
                    Forum spam filter sometimes being funky... Should be there now.
                    Michael Larabel
                    https://www.michaellarabel.com/

                    Comment

                    Working...
                    X