Announcement

Collapse
No announcement yet.

LLVM Clang 6.0 Now Defaults To C++14

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

  • LLVM Clang 6.0 Now Defaults To C++14

    Phoronix: LLVM Clang 6.0 Now Defaults To C++14

    Up to now LLVM's Clang C/C++ compiler has defaulted to using C++98/C++14 as its default C++ standard, but fortunately that's no more...

    http://www.phoronix.com/scan.php?pag...Clang-60-CPP14

  • #2
    Does matching GCC in this context make sense? I can understand the desire to be command line compatible in most cases but in thus case it just feels regressive. Beyond that does C++17 throw that many compatibility curves, that is features that break older legal code?

    Comment


    • #3
      Originally posted by phoronix View Post
      Up to now LLVM's Clang C/C++ compiler has defaulted to using C++98/C++14 as its default C++ standard
      That doesn't make any sense :-P

      Comment


      • #4
        Originally posted by RealNC View Post
        That doesn't make any sense :-P
        Fixed, thanks. Had intended as "C++98/GNU++98"
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by wizard69 View Post
          Does matching GCC in this context make sense? I can understand the desire to be command line compatible in most cases but in thus case it just feels regressive. Beyond that does C++17 throw that many compatibility curves, that is features that break older legal code?
          I think it's a sensible decision: Clang is trying to ensure that code written against gcc works fine with as little modification as possible on Clang.

          I can't think of anything in C++17 that breaks legal C++14 code, apart from removing a couple of deprecated stuff from the standard library.

          Comment


          • #6
            Originally posted by Xelix View Post

            I think it's a sensible decision: Clang is trying to ensure that code written against gcc works fine with as little modification as possible on Clang.

            I can't think of anything in C++17 that breaks legal C++14 code, apart from removing a couple of deprecated stuff from the standard library.
            There are some corner cases. For example, classes with base classes can still be aggregates. That means this code breaks, whereas I worked before:

            Code:
            struct A{ protected: A(){} };
            struct B : A {};
            B b{};
            And also there's P0522R0 breaking code, which clang disable by default. https://stackoverflow.com/questions/...-breaking-code

            Also, if you ever did function type introspection, you'd have to update your code for the 26 possible new function pointer types.

            Comment


            • #7
              I tested using C++17 on a C++11 codebase and code compiled but behaved differently during runtime. Can`t really fault C++17 (using namespace std is a horrible but common crime), the reason was that new std::empty was being used instead of an own empty function with different semantics.
              So there is enough that can go wrong.

              Comment


              • #8
                Originally posted by Xelix View Post

                I think it's a sensible decision: Clang is trying to ensure that code written against gcc works fine with as little modification as possible on Clang.

                I can't think of anything in C++17 that breaks legal C++14 code, apart from removing a couple of deprecated stuff from the standard library.
                If you have function to a noexcept declared function and cakes the address of it, the type now includes the noexcept part in C++17. It breaks some code, though fortunately it is a corner case. There are one or two other special casess that were broken.

                Comment

                Working...
                X