> Granted, the state of C++ on MacOS is embarrassingly bad.
In what sense? Apple keeps Clang up to date on macOS, and it is essentially no work to get the associated Clang tooling and other C++ tools (valgrind, etc) installed through something like homebrew.
Actually, not especially. The system compiler that ships with Xcode is still quite old and the libraries are quite out of date. For example, though the most recent Xcode finally added -std=c++17 it still lacks core library features like std::variant. I wish they could keep close to mainline but for whatever reason they can't.
I'm not quite clear about your point. The version of Clang that Apple ships, for whatever reason, is pretty far behind the released Clang. I cited std::variant as an example of something which has been in the public Clang for ages.
As far as compiler support goes, Clang supports all of C++17 except for P0522R0 which is a defect report (ambiguity in specification) so cannot be implemented as written. Ditto GCC.
However std::variant is a library entity, not a compiler entity, and indeed, the libraries are a bit behind. Neither GCC's nor LLVM's runtime library support the parallelism extensions and have other gaps in areas exotic (memory, unfortunately which I would like to use) and prosaic (filesystem, which though I'd like to use it as well don't really care about). But they have been solid on C++17 core functionality for quite a long time.
C++ isn't as important to Apple as Swift (or even, still, ObjC) and C++17 is pretty new, so one can hardly blame Apple for this, especially since it's so trivial to simply use another compiler.
No it's awful. They are most certainly not up to date, and even worse, the compilers they ship that advertise certain flags aren't even necessarily feature complete. A glaring example of this was the lack of thread_local support for ages.
Yup. It was only about a year ago that the undefined behaviour sanitizer stopped segfaulting when I turned it on, despite it being clearly "documented" in the man page. I'm amazed that a company with the resources of Apple has such shoddy developer tools.
"AppleClang" is some strange fork with some features (both compiler and library) omitted or broken. OpenMP, for example, is one thing I've been missing for a good while; I've not checked if that's now present with new releases. I can understand adding extra functionality to a fork, like Objective C and swift stuff, but dropping bits is strange.
It's due to issues like this that I do all our clang testing on FreeBSD, where it's a more vanilla build of the llvm codebase, and I treat AppleClang as a wholly separate compiler variant which requires independent testing.
I think clang's OpenMP implementation might not be 100% ready? Many FreeBSD ports that have an OPENMP option straight up use gcc when that option is enabled.
In what sense? Apple keeps Clang up to date on macOS, and it is essentially no work to get the associated Clang tooling and other C++ tools (valgrind, etc) installed through something like homebrew.