Announcement

Collapse
No announcement yet.

Many Features Proposed For C++14

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

  • Many Features Proposed For C++14

    Phoronix: Many Features Proposed For C++14

    C++14 is the next update for the C++ programming language. While slated as only a minor extension to C++11, there are several new features being proposed...

    http://www.phoronix.com/vr.php?view=MTMzNzY

  • #2
    So OpenMP would be considered a standard library and replace <threads>?

    Comment


    • #3
      No it will add not replace threads.

      Comment


      • #4
        Originally posted by Ericg View Post
        So OpenMP would be considered a standard library and replace <threads>?
        OpenMP is a high-level threading API. It couldn't possibly replace <threads>.

        Comment


        • #5
          All I want is modules. Pls Herb. End the textual inclusion nightmare.

          Comment


          • #6
            Originally posted by zanny View Post
            All I want is modules. Pls Herb. End the textual inclusion nightmare.
            ++++

            But I don't think modules will land this decade, if ever. Because adding a fifth parameter-passing method is more important than, say, not crashing whenever you throw an exception from a shared library. Who cares about modules or encapsulation or terrible copy-paste coding (sorry, "textual inclusion"), now you can have rvalue-references and a dozen standard optional random number generators!

            Comment


            • #7
              having written high performance massively parallel software my experience with openMP is quite unimpressive. Gains are typically quite sub linear, more log-like. It's okay as a stop gap for trying to upgrade old non thread safe software. IMHO new vector unit technology can be dramatically faster. In my experience there are 2 levels of parallelization: instruction level. best left to vectorization techniques, and task level parallelism which is an issue of software design and not a coding problem.

              Comment


              • #8
                Bah C++11 was awesome, but this C++14 list looks like it was writen by somebody who want to code Java. It is all extensions to the standard library that no one uses anyway. Yawn.

                Comment


                • #9
                  Originally posted by bnolsen View Post
                  having written high performance massively parallel software my experience with openMP is quite unimpressive. Gains are typically quite sub linear, more log-like. It's okay as a stop gap for trying to upgrade old non thread safe software. IMHO new vector unit technology can be dramatically faster. In my experience there are 2 levels of parallelization: instruction level. best left to vectorization techniques, and task level parallelism which is an issue of software design and not a coding problem.
                  This depends very much on your algorithm. Most importantly how large the thread copying overhead is compared to the actualy workload of each thread and how much of your algorithm needs to be inside critical sections.

                  If you apply it to the outermost loops, with each loop iteration doing lots and lots of work with minimal critical sections, gains can be very close to linear, in my experience.

                  OpenMP is a wonderful, wonderful way to make software multi-threaded without major rewrites.

                  Comment


                  • #10
                    Originally posted by pingufunkybeat View Post
                    This depends very much on your algorithm. Most importantly how large the thread copying overhead is compared to the actualy workload of each thread and how much of your algorithm needs to be inside critical sections.

                    If you apply it to the outermost loops, with each loop iteration doing lots and lots of work with minimal critical sections, gains can be very close to linear, in my experience.

                    OpenMP is a wonderful, wonderful way to make software multi-threaded without major rewrites.
                    Agreed. We use it for stochastic simulations, where each path numerically solves a set of stochastic partial differential equations with different noises. The processes only need to communicate infrequently to average results. Speed up is basically linear up to at least 12 cores (unless you become limited by memory bandwidth issues).

                    Comment


                    • #11
                      How about designated initializers?

                      They've been in C since C99. Maybe 15 years is enough time for useful features to make it from C into C++?

                      Comment


                      • #12
                        Originally posted by brouhaha View Post
                        They've been in C since C99. Maybe 15 years is enough time for useful features to make it from C into C++?
                        C++ includes all of C, its just a matter of whether or not its being used.

                        Comment


                        • #13
                          Originally posted by Ericg View Post
                          C++ includes all of C, its just a matter of whether or not its being used.
                          C++ doesn't include all of C, it includes (almost) all of C89 and some cherry picked features from C99. Designated initializers are non-standard in C++ and there are minor incompatibilities like 'c' being a char literal instead of an int and explicit casts being required from void *.

                          Comment


                          • #14
                            Originally posted by strcat View Post
                            C++ doesn't include all of C, it includes (almost) all of C89 and some cherry picked features from C99. Designated initializers are non-standard in C++ and there are minor incompatibilities like 'c' being a char literal instead of an int and explicit casts being required from void *.
                            In defense of C++ on the char thing (though it isn't much of a defense) any reasonable modern language would be implementing chars as code points which, by being variable size, can't be contained in a fixed 8 bit integral value (does the cast return 2 bytes? where do you put / refer to those? Does it just return a short? What if its a 3 byte code point?) Though, C++ still uses ASCII raw chars and requires writing nonsense like u8"asdfpattie" with auto types or wchar_t nonsense (char16_t, char32_t... bleh).

                            C doesn't have anything close to unicode support, though. It says something that Rust / Go, the two "newer" popular native languages are both only unicode.

                            Comment


                            • #15
                              Originally posted by zanny View Post
                              In defense of C++ on the char thing (though it isn't much of a defense) any reasonable modern language would be implementing chars as code points which, by being variable size, can't be contained in a fixed 8 bit integral value (does the cast return 2 bytes? where do you put / refer to those? Does it just return a short? What if its a 3 byte code point?) Though, C++ still uses ASCII raw chars and requires writing nonsense like u8"asdfpattie" with auto types or wchar_t nonsense (char16_t, char32_t... bleh).

                              C doesn't have anything close to unicode support, though. It says something that Rust / Go, the two "newer" popular native languages are both only unicode.
                              It's actually an int in C, and a char in C++; I get the impression you interpreted it the other way. I don't know why it's an int in C, but the rationale for breaking compatibility in C++ was to avoid confusing people by calling an int function overload with a literal like 'a' . In C, it's not nearly as noticeable.

                              Comment

                              Working...
                              X