4 ms·

> 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 asso

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

gumby 9y ago
> Apple keeps Clang up to date on macOS, 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.
- jcelerier 9y ago
  > The system compiler that ships with Xcode is still quite old quite old, quite old... -std=c++17 was only added in clang 5 released in september, 3 months ago. AFAIK current Xcode is based on Clang 4.
- ezoe 9y ago
  No C++ compilers currently implemented the full C++17 standard at this time.
  - gumby 9y ago
    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.
banachtarski 9y ago
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.
- MrBingley 9y ago
  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.
rleigh 9y ago
"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.
- floatboth 9y ago
  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.

gumby 9y ago

> Apple keeps Clang up to date on macOS, 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.

jcelerier 9y ago
> The system compiler that ships with Xcode is still quite old quite old, quite old... -std=c++17 was only added in clang 5 released in september, 3 months ago. AFAIK current Xcode is based on Clang 4.
ezoe 9y ago
No C++ compilers currently implemented the full C++17 standard at this time.
- gumby 9y ago
  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.

banachtarski 9y ago

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.

MrBingley 9y ago
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.

rleigh 9y ago

"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.

floatboth 9y ago
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.