Announcement

Collapse
No announcement yet.

LLVM Clang 6.0 Now Defaults To C++14

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

  • carewolf
    replied
    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.

    Leave a comment:


  • discordian
    replied
    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.

    Leave a comment:


  • gufide
    replied
    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.

    Leave a comment:


  • Xelix
    replied
    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.

    Leave a comment:


  • Michael
    replied
    Originally posted by RealNC View Post
    That doesn't make any sense :-P
    Fixed, thanks. Had intended as "C++98/GNU++98"

    Leave a comment:


  • RealNC
    replied
    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

    Leave a comment:


  • wizard69
    replied
    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?

    Leave a comment:


  • phoronix
    started a topic LLVM Clang 6.0 Now Defaults To C++14

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