Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Overview of C++ language support in Apple Clang

developer.apple.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Overview of C++ language support in Apple Clang

#21

Post by lenkite »

Someone wrote: post #16
saurik wrote: post #6

Earlier quoted context omitted.

FWIW, I don't know how much they actually "deviate" (and in fact I do think they have a bunch of likely-needless changes) but they definitely lag a bit what they ship, so the core issue is just that they are behind a version or two, so the differences are almost entirely just "the stuff introduced in clang/libc++ 15/16+" with maybe one or two backports. If it makes you feel any better, the Android NDK copy of clang i…

I think Apple’s clang is the one they build the OS with, and they don’t want to run the risk of introducing a compiler bug late into a project. So, they pick what’s current early in a project and stick with it. They may add a few backports of bug fixes to that, but that’s it. IMO, that’s a good strategy.

Compiler version used to compile the OS mandating same compiler version to compile all apps for the OS is a very head-scratching strategy.

Re: Overview of C++ language support in Apple Clang

#22

Post by ninkendo »

lenkite wrote: post #21
Someone wrote: post #16

Earlier quoted context omitted.

I think Apple’s clang is the one they build the OS with, and they don’t want to run the risk of introducing a compiler bug late into a project. So, they pick what’s current early in a project and stick with it. They may add a few backports of bug fixes to that, but that’s it. IMO, that’s a good strategy.

Compiler version used to compile the OS mandating same compiler version to compile all apps for the OS is a very head-scratching strategy.

It’s commonly known as dogfooding, and it’s a very common (and I’d argue, the correct) strategy. It’s more head scratching IMO for there to be two standards on compiler stability.

Re: Overview of C++ language support in Apple Clang

#25

Post by typesanitizer »

Athas wrote: post #20

Does anyone know why the clang that comes with macOS does not support OpenMP, even though upstream clang does? I use OpenMP to teach basic parallel programming, and it is really annoying that the macOS users have to install another compiler to get it working. (The problem is exacerbated by the ridiculous fact that macOS includes a 'gcc' alias that is not in fact GCC, and which risks shadowing a proper GCC that the st…

I don't know the answer to your original question, but based on this StackOverflow answer (https://stackoverflow.com/a/60564952/2682729), it seems like a small compiler wrapper should do the trick to get the same experience across platforms without having to install another compiler.

Depending on the platforms you need to support, a more heavyweight but more reproducible solution would be to use a fixed LLVM toolchain, say using Bazel.

Re: Overview of C++ language support in Apple Clang

#26

Post by cpgxiii »

Athas wrote: post #20

Does anyone know why the clang that comes with macOS does not support OpenMP, even though upstream clang does? I use OpenMP to teach basic parallel programming, and it is really annoying that the macOS users have to install another compiler to get it working. (The problem is exacerbated by the ridiculous fact that macOS includes a 'gcc' alias that is not in fact GCC, and which risks shadowing a proper GCC that the st…

When Apple initially moved to clang instead of GCC, clang did not support OpenMP. Apple chose vendor lock-in with Grand Central Dispatch (in the same way they would chose vendor lock-in with Metal years later) rather than invest the time in the existing work on a competitive clang OpenMP implementation.

I think the track record of Apple on supporting anything standardized speaks for itself (see OpenGL, OpenCL, OpenMP, C & C++ features, etc) - Apple gives as few fucks about cross-platform development as possible. Apple sees its platform being so valuable that developers will jump through whatever hoops Apple puts in their way, and largely their developers put up with this.

Re: Overview of C++ language support in Apple Clang

#27

Post by trelane »

cpgxiii wrote: post #26
Athas wrote: post #20

Does anyone know why the clang that comes with macOS does not support OpenMP, even though upstream clang does? I use OpenMP to teach basic parallel programming, and it is really annoying that the macOS users have to install another compiler to get it working. (The problem is exacerbated by the ridiculous fact that macOS includes a 'gcc' alias that is not in fact GCC, and which risks shadowing a proper GCC that the st…

When Apple initially moved to clang instead of GCC, clang did not support OpenMP. Apple chose vendor lock-in with Grand Central Dispatch (in the same way they would chose vendor lock-in with Metal years later) rather than invest the time in the existing work on a competitive clang OpenMP implementation. I think the track record of Apple on supporting anything standardized speaks for itself (see OpenGL, OpenCL, OpenMP…

> Apple chose vendor lock-in with Grand Central Dispatch

I will note here that this vendor lock-in is one of the (if not the) main reasons Apple et al. moved away from the GPLed GCC.

The ability to lock in users is the central difference between open source and Free Software.

As such, this is WAI from the Open Source perspective.

Re: Overview of C++ language support in Apple Clang

#28

Post by Longhanks »

_eojb wrote: post #19
Someone wrote: post #16

Earlier quoted context omitted.

I think Apple’s clang is the one they build the OS with, and they don’t want to run the risk of introducing a compiler bug late into a project. So, they pick what’s current early in a project and stick with it. They may add a few backports of bug fixes to that, but that’s it. IMO, that’s a good strategy.

Contrasting opinion, it's a terrible strategy. Limiting the entire ecoystem of devs on your platform to features that have not only shipped but stabilized over 5 years prior on other platforms is nonsensical. Compare to MSFT, which is frankly ahead of the curve when it comes to compiler feature support, and even has the entire STL open sourced.

> even has the entire STL open sourced.

You do realize that everything from llvm/clang, gcc, libc++ to libstdc++ is open source? MSVC is late in that regard (and the compiler itself is as closed as can be).

Re: Overview of C++ language support in Apple Clang

#29

Post by cornstalks »

cpgxiii wrote: post #26
Athas wrote: post #20

Does anyone know why the clang that comes with macOS does not support OpenMP, even though upstream clang does? I use OpenMP to teach basic parallel programming, and it is really annoying that the macOS users have to install another compiler to get it working. (The problem is exacerbated by the ridiculous fact that macOS includes a 'gcc' alias that is not in fact GCC, and which risks shadowing a proper GCC that the st…

When Apple initially moved to clang instead of GCC, clang did not support OpenMP. Apple chose vendor lock-in with Grand Central Dispatch (in the same way they would chose vendor lock-in with Metal years later) rather than invest the time in the existing work on a competitive clang OpenMP implementation. I think the track record of Apple on supporting anything standardized speaks for itself (see OpenGL, OpenCL, OpenMP…

OpenMP vs GCD? That’s apples and oranges. They’re not even in the same ballpark. I can’t fathom how GCD fills the same needs OpenMP targets, nor can I see how GCD is Apple’s “no” response to OpenMP.

And GCD is open source (not sure when the source was first made available, though). It even supports Linux (thanks to Swift) though that’s recent.

Re: Overview of C++ language support in Apple Clang

#30

Post by sesuximo »

_eojb wrote: post #19
Someone wrote: post #16

Earlier quoted context omitted.

I think Apple’s clang is the one they build the OS with, and they don’t want to run the risk of introducing a compiler bug late into a project. So, they pick what’s current early in a project and stick with it. They may add a few backports of bug fixes to that, but that’s it. IMO, that’s a good strategy.

Contrasting opinion, it's a terrible strategy. Limiting the entire ecoystem of devs on your platform to features that have not only shipped but stabilized over 5 years prior on other platforms is nonsensical. Compare to MSFT, which is frankly ahead of the curve when it comes to compiler feature support, and even has the entire STL open sourced.

You can absolutely use a different compiler as an apple dev. Just might be a touch tougher to set up a non-standard build
Post reply on HN