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...

    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
    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