5 ms·

gcc is further along with c++20 support, which makes clang nonstarter these days.

gavinray 4y ago
I use Clang with GCC's C++ stdlib. You can do this with a single flag: clang++ -std=c++2b --gcc-toolchain=/usr/local/gcc-13.0.0-dev Now I get to use LLVM with the latest C++23 support from GCC. Have your cake and eat it, too =)
- jeffbee 4y ago
  Even clang 15 cannot build the C++20 ranges/views support from GNU libstdc++, no matter how many flags you give it.
  - gavinray 4y ago
    You don't have to _build_ anything, you are simply using the Clang compiler with the GCC standard library The C++ compiler and the C++ standard library exist as separate components. You're free to mix and match them. You just need to configure the relevant compiler and linker flags (which may be harder on GCC than Clang, for instance) And if you mean to just #include <ranges>, that's not right at all For instance, installing LLVM/Clang on Fedora Rawhide uses Redhat GCC 12.2 as the default stdlib right now, and including <ranges> works perfectly fine: [user@MSI ~]$ clang++-15 -v clang version 15.0.0 (Fedora 15.0.0-5.fc38) Target: x86_64-redhat-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12 EDIT: I take it back, you're right. You can #include it but if you try to use parts of it, it will cause compile errors
    - gpderetta 4y ago
      > The C++ compiler and the C++ standard library exist as separate components this is not really true. Aside from the fact that the standard library need not be a library at all and could just be built-in, in practice the standard library provided by a compiler is intimately tied with that (specific version of the) compiler. libstdc++ uses plenty of GCC specific non-standard extensions and relies on implementation specific and often undocumented behaviour. Clang tries to implement all the same extensions and GCC developers try not to break clang support too often (sometimes even providing clang specific workarounds or gating out non-implemented features), but as you have experienced, breakage does happen form time to time.
      - jeffbee 4y ago
        In this case the breakage is not caused by extensions, though. It's caused by a bug in the C++20 support in clang, at least according to the GNU people.

I use Clang with GCC's C++ stdlib. You can do this with a single flag: clang++ -std=c++2b --gcc-toolchain=/usr/local/gcc-13.0.0-dev Now I get to use LLVM with the latest C++23 support from GCC. Have your cake and eat it, too =)

jeffbee 4y ago
Even clang 15 cannot build the C++20 ranges/views support from GNU libstdc++, no matter how many flags you give it.
- gavinray 4y ago
  You don't have to _build_ anything, you are simply using the Clang compiler with the GCC standard library The C++ compiler and the C++ standard library exist as separate components. You're free to mix and match them. You just need to configure the relevant compiler and linker flags (which may be harder on GCC than Clang, for instance) And if you mean to just #include <ranges>, that's not right at all For instance, installing LLVM/Clang on Fedora Rawhide uses Redhat GCC 12.2 as the default stdlib right now, and including <ranges> works perfectly fine: [user@MSI ~]$ clang++-15 -v clang version 15.0.0 (Fedora 15.0.0-5.fc38) Target: x86_64-redhat-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12 EDIT: I take it back, you're right. You can #include it but if you try to use parts of it, it will cause compile errors
  - gpderetta 4y ago
    > The C++ compiler and the C++ standard library exist as separate components this is not really true. Aside from the fact that the standard library need not be a library at all and could just be built-in, in practice the standard library provided by a compiler is intimately tied with that (specific version of the) compiler. libstdc++ uses plenty of GCC specific non-standard extensions and relies on implementation specific and often undocumented behaviour. Clang tries to implement all the same extensions and GCC developers try not to break clang support too often (sometimes even providing clang specific workarounds or gating out non-implemented features), but as you have experienced, breakage does happen form time to time.
    - jeffbee 4y ago
      In this case the breakage is not caused by extensions, though. It's caused by a bug in the C++20 support in clang, at least according to the GNU people.