Hacker News Reader

Hacker News

Comment by synergy20 | Hacker News Reader

Parent Full thread

synergy20

its lagging on c++20 support made many tools esp clang-tidy useless for c++20 development

View on HN

I count only 4, small features from C++20 not supported by Clang here:

https://en.cppreference.com/w/cpp/compiler_support#cpp20

For core library features, you can just clone GCC from master, and use

  --gcc-toolchain=/usr/local/gcc-dev

To use the latest "libstdc++" and get all the C++23 stdlib features from GCC while benefiting from the LLVM compiler toolchain

I haven't found "clangd" lacking at all for C++20 or C++23 development, but it does require that you configure it properly.

C++20 language support is almost all done. Even C++23 is nearing to the finish line. I see this type of FUD spread more and more around HN which hasn't been the case before. I wonder why.

What FUD, clang 15 can't certainly not compile my C++ projects written with C++20 modules, and cppreference clearly shows where it is.

I wasn't referring to your comment but saying that clang is lagging and is unusable with C++20 while there are only 4 features out of 69 of them in total (!) missing, then yes, by my book this is spreading the FUD.

The language support might be nearly done but libc++ definitely does not have full C++20 support. For example, ranges, a HUGE feature in C++20, are disabled by default in libc++ (as of version 15, the latest stable release). As another example for a feature I want, std::source_location isn't implemented in libc++ even though it's existed in GCC/libstdc++ for many years now. In this example Clang has had the language support for implementing std::source_location for a while, but it hasn't been merged into libc++ for various reasons (last I checked there was a diff on phabricator that implemented it but there was some debate about the ABI that was being introduced, or something of that nature).

I don't think it's necessarily FUD, many C++ users don't understand the difference between core language features and standard library features. And even when you do understand the difference, with many features (e.g. std::source_location) you can't actually use the feature if libc++ doesn't have it, so the fact that clang itself supports the language feature is a moot point and irrelevant to end users.

I saw another comment explaining how to use libstdc++ with clang. Sure you can do this, but who actually wants to compile their code this way? Especially since it means you need to upgrade your compiler and standard library separately, on different release cadences. For most people this is way too much headache, they'd rather just not use the new features and wait until they're in libc++. You can also compile llvm with custom options to enable experimental features that aren't fully developed (like ranges), but who really wants to do this? Building a custom compiler/libc++ is a huge headache and the features are disabled by default for a reason anyway.

Just to be clear I love LLVM/Clang/libc++ and am huge advocates of them. But there's nothing wrong with pointing out flaws and where there are gaps compared to other implementations.

FWIW, if you're on a distro with a default GCC toolchain, it's pretty typical to use clang together with libstdc++. E.g. if you use clang on Fedora, you're using libstdc++ by default. You have to explicitly pass -stdlib=libc++ to use libc++ instead. So I wouldn't consider this a particularly unusual build configuration.

Of course, it's different on distros with a default Clang toolchain, like macOS, where building with anything but libc++ would be pretty unusual.

I use clang with libstdc++ in C++20 mode. Clang does this by default if you have both clang and g++ installed on Ubuntu.

Reply on news.ycombinator.com