3 ms·

Big projects move slowly to newer standards. E.g.[1]: > Chromium targets C++14; C++17 support is not expected before mid-2021. [1]: <https://chromium.googleso

Big projects move slowly to newer standards. E.g.[1]: > Chromium targets C++14; C++17 support is not expected before mid-2021. [1]: <https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md https://chromium.googlesource.com/chromium/src/+/master/styl...>

pjmlp 6y ago
I wouldn't consider Chromium a good example though, given how Google considers most of modern C++ not welcomed.
- hvdijk 6y ago
  Chromium is the reason a patch I had recently submitted to LLVM to fix a conformance issue in their preprocessor was reverted: it broke Chromium, because Chromium doesn't just require a preprocessor that offers guarantees in areas the standard doesn't, it specifically requires a preprocessor that does not conform to the C++ standard. No idea on whether they're putting in the work on fixing their code to at least make it valid for some version of C++.
  - DoofusOfDeath 6y ago
    Thanks for reporting this. It's the first evidence I've heard of someone (Google?) abusing their power with LLVM in order to protect Google's products. Mind sharing a link to your submission's discussion thread(s)?
    - hvdijk 6y ago
      I don't think it's productive to speak of the LLVM maintainer's decision as an abuse of power. The actual revert happened in contradiction of documented LLVM policies (which, according to the maintainer, do not match actual LLVM policies), so I did take issue with that, but the maintainer wanted to first make sure clang had a different conforming extension that Chromium could use instead before removing the non-conforming extension, and assuming that a non-Google project would be given the same treatment -- and I have no reason to assume otherwise -- I think that is defensible. The change was <https://reviews.llvm.org/D91913 https://reviews.llvm.org/D91913>, addressing a conflict between GCC's ,##__VA_ARGS__ extension with the C and C++ standards in the corner case where a macro, let's call it FOO, takes no named parameters and is invoked as FOO(). In standards-conforming C modes, clang already acts as required by the standard, but in meant-to-be-conforming C++ modes, it does not.
      - DoofusOfDeath 6y ago
        Thanks for the context! You saved me from foolishly wandering into crowd-with-pitchforks mode.
        gpderetta 6y ago
        I was also reaching for my pitchfork, but in this case there is probably more code in the wild that relies on the (very useful) GCC extension as opposed to the standard behaviour.
        hvdijk 6y ago
        I'm not too sure about the "more code in the wild" that would be broken though. GCC already disables this extension, in the cases where it conflicts with the standard, in -std=c++11 mode. I expect almost all code to either use -std=c++11 consistently, in which case it would already be broken with GCC, or to use -std=gnu++11 consistently, in which case it would continue to work with clang even after that patch. Chromium is weird in that it builds with -std=c++11 if building with clang, and it builds with -std=gnu++11 if building with GCC. (Change 11 to 14 or whatever else as needed.)
        gpderetta 6y ago
        Thas clang distinguish between g++11 and c++11? If so chrome should probably use the former.
        hvdijk 6y ago
        Yup, I made sure my change would make clang agree with GCC as far as this particular extension is concerned, so it was fully enabled in -std=gnu++11 mode and only enabled where it didn't conflict with standard C++ in -std=c++11 mode. I felt the same way that Chromium should just use the same flags for clang as for GCC if they want to keep using this extension, but they don't.
  - deleted 6y ago
    [deleted]

pjmlp 6y ago

I wouldn't consider Chromium a good example though, given how Google considers most of modern C++ not welcomed.

hvdijk 6y ago
Chromium is the reason a patch I had recently submitted to LLVM to fix a conformance issue in their preprocessor was reverted: it broke Chromium, because Chromium doesn't just require a preprocessor that offers guarantees in areas the standard doesn't, it specifically requires a preprocessor that does not conform to the C++ standard. No idea on whether they're putting in the work on fixing their code to at least make it valid for some version of C++.
- DoofusOfDeath 6y ago
  Thanks for reporting this. It's the first evidence I've heard of someone (Google?) abusing their power with LLVM in order to protect Google's products. Mind sharing a link to your submission's discussion thread(s)?
  - hvdijk 6y ago
    I don't think it's productive to speak of the LLVM maintainer's decision as an abuse of power. The actual revert happened in contradiction of documented LLVM policies (which, according to the maintainer, do not match actual LLVM policies), so I did take issue with that, but the maintainer wanted to first make sure clang had a different conforming extension that Chromium could use instead before removing the non-conforming extension, and assuming that a non-Google project would be given the same treatment -- and I have no reason to assume otherwise -- I think that is defensible. The change was <https://reviews.llvm.org/D91913 https://reviews.llvm.org/D91913>, addressing a conflict between GCC's ,##__VA_ARGS__ extension with the C and C++ standards in the corner case where a macro, let's call it FOO, takes no named parameters and is invoked as FOO(). In standards-conforming C modes, clang already acts as required by the standard, but in meant-to-be-conforming C++ modes, it does not.
    - DoofusOfDeath 6y ago
      Thanks for the context! You saved me from foolishly wandering into crowd-with-pitchforks mode.
      - gpderetta 6y ago
        I was also reaching for my pitchfork, but in this case there is probably more code in the wild that relies on the (very useful) GCC extension as opposed to the standard behaviour.
        hvdijk 6y ago
        I'm not too sure about the "more code in the wild" that would be broken though. GCC already disables this extension, in the cases where it conflicts with the standard, in -std=c++11 mode. I expect almost all code to either use -std=c++11 consistently, in which case it would already be broken with GCC, or to use -std=gnu++11 consistently, in which case it would continue to work with clang even after that patch. Chromium is weird in that it builds with -std=c++11 if building with clang, and it builds with -std=gnu++11 if building with GCC. (Change 11 to 14 or whatever else as needed.)
        gpderetta 6y ago
        Thas clang distinguish between g++11 and c++11? If so chrome should probably use the former.
        hvdijk 6y ago
        Yup, I made sure my change would make clang agree with GCC as far as this particular extension is concerned, so it was fully enabled in -std=gnu++11 mode and only enabled where it didn't conflict with standard C++ in -std=c++11 mode. I felt the same way that Chromium should just use the same flags for clang as for GCC if they want to keep using this extension, but they don't.
- deleted 6y ago
  [deleted]