Announcement

Collapse
No announcement yet.

Coroutines & Modules Added For C++20

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

  • Coroutines & Modules Added For C++20

    Phoronix: Coroutines & Modules Added For C++20

    The ISO C++ committee has wrapped up its winter meeting in Hawaii that also served as the last meeting for approving new features for the upcoming C++20 revision to the C++ programming language...

    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
    I am quite happy to see that Concepts has been included as well.

    Comment


    • #3
      Oh damn, they're really getting all the TSes in now, C++20 is going to be completely amazing.

      Comment


      • #4
        It's great to see C++ evolving as a mature, well defined, and vendor-independent programming language!
        What a difference to all those short-lived hype languages that pop up only to disappear a few years later, or those company-owned languages (like Java) that are a patent- and copyright-minefield for everybody.

        I certainly do not like every programming paradigm that has made it into the C++ standard, but the great thing about C++ is that it does not force you to follow one particular paradigm, you can always opt to just not use certain language features that you don't like.

        Comment


        • #5
          Modules?
          FUCK YES

          Comment


          • #6
            It will be very interesting to see how C++20's utility compares to Rust.

            Comment


            • #7
              How are Modules supposed to work?

              Comment


              • #8
                Originally posted by atomsymbol
                [I]C++ forces the programmer to define types of fields of a struct/class before the struct/class is defined. This is putting a very strict constraint on the ordering of struct data types in the source code. You cannot call a virtual method (defined elsewhere !!!) before the struct definition has seen the definition of the types of its fields, while obviously the knowledge of fields is immaterial to the virtual method call. This has negative implications for the length of compilation time, because some header files need to be included just to expose field types to the compiler (even if those fields are private).
                This is why a lot of people use abstract interface classes or the PImpl pattern.

                Originally posted by atomsymbol
                It is an example of a lousy language&compiler design that most C++ programmers either have learned to silently ignore or have never thought of to exist, for 34 years!
                Well, C started out life as portable substitute for assembly language. C++ built on it, with the idea that you don't want to pay for features you're not using. That leaves the door open to C-level (or even asm-level) performance, if you're careful. Once you start to dispense with that principle, there's one less argument to use C++.

                I don't imagine even modules can let you instantiate a type without visibility into its definition, including those of all its type dependencies.

                Comment


                • #9
                  Originally posted by coder View Post
                  I don't imagine even modules can let you instantiate a type without visibility into its definition, including those of all its type dependencies.
                  From how I understand modules to work, it is left up to the compiler to pass the necessary information (AST etc) between modules where necessary, instead of being the job of the preprocessor - which just naively inlines the entire header and all its includes.
                  Skipping the preprocessor here speeds up compiling immensely as you no longer need to parse headers more than once between correctly built modules, but you still get full visibility into the definition, just as an AST or other compiler-friendly datastructure.

                  Comment


                  • #10
                    Originally posted by coder View Post
                    I don't imagine even modules can let you instantiate a type without visibility into its definition, including those of all its type dependencies.
                    It's a statically typed language (it's a feature, not a drawback,) so that should go without saying.

                    Comment

                    Working...
                    X