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

41–50 of 50 posts

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

#41

Post by ninepoints »

Longhanks wrote: post #28
_eojb wrote: post #19

Earlier quoted context omitted.

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

Yes I hack on llvm and clang. Where can I submit a PR to Apple Clang?

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

#42

Post by ninkendo »

menaerus wrote: post #34
ninkendo wrote: post #22

Earlier quoted context omitted.

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.

There are no two standards on compiler stability - there is one and it is called ABI. What Apple chose is rather an outstanding case and not really common when you consider all the operating systems and their flavors.

If we were to presuppose that Apple already has a new compiler version that works with new C++ features, but doesn’t think it’s ready yet, than IMO it stands to reason that they’re also not confident that the ABI emitted by said compiler will be something they’re ready to support forever. It’s a bad idea to say “go ahead and compile with an unsupported compiler, and we’ll just support the ABI it emits in perpetuity even though we have already admitted it’s not stabilized yet.”

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

#43

Post by watersb »

sesuximo wrote: post #30
_eojb wrote: post #19

Earlier quoted context omitted.

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

Sorry, this might be a dumb question, but I'm not sure what you mean by "as an Apple dev".

I assume you mean "as a developer [anybody] developing software on an Apple platform".

I would be surprised if Apple employees were free to choose their compiler.

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

#44

Post by menaerus »

ninkendo wrote: post #42
menaerus wrote: post #34

Earlier quoted context omitted.

There are no two standards on compiler stability - there is one and it is called ABI. What Apple chose is rather an outstanding case and not really common when you consider all the operating systems and their flavors.

If we were to presuppose that Apple already has a new compiler version that works with new C++ features, but doesn’t think it’s ready yet, than IMO it stands to reason that they’re also not confident that the ABI emitted by said compiler will be something they’re ready to support forever. It’s a bad idea to say “go ahead and compile with an unsupported compiler, and we’ll just support the ABI it emits in perpetuity e…

How else do you imagine different compiler vendors with loath of varying compiler versions work on other Unices?

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

#45

Post by ninkendo »

menaerus wrote: post #44
ninkendo wrote: post #42

Earlier quoted context omitted.

If we were to presuppose that Apple already has a new compiler version that works with new C++ features, but doesn’t think it’s ready yet, than IMO it stands to reason that they’re also not confident that the ABI emitted by said compiler will be something they’re ready to support forever. It’s a bad idea to say “go ahead and compile with an unsupported compiler, and we’ll just support the ABI it emits in perpetuity e…

How else do you imagine different compiler vendors with loath of varying compiler versions work on other Unices?

They define a de facto ABI for their compiler, and once they’re confident enough that the code emitted by their compiler actually works and adheres to it, they take it out of beta and say it’s ready to use. No sooner than that. Not sure what you’re asking here.

Remember that supporting C++ features isn’t just about emitting code, it’s about the implementation of libstdc++/libc++ that you have to make sure you don’t paint yourself into a corner with. It’s easy to accidentally write code that needs to be linked to one way, then later on in the development cycle, subtly change it in a way that changes a symbol, or a type layout, etc. This is all fiddly work that they have to spend time getting right.

You mention other compiler vendors: I remember very distinctly times when GCC would change the ABI to libstdc++. I was running Debian sid at the time and there was basically a month where the OS was not usable at all, as packages had to be recompiled against the new libstdc++.

These kinds of issues happen where, if you let people use a complier (and its corresponding stdlib implementation) before it’s ready, you may find that you have to break ABI in order to fix issues with your new language support, and you leave people stranded who may have already compiled their code against the old stdlib.

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

#46

Post by jcelerier »

theirixhn wrote: post #39
jcelerier wrote: post #33

Earlier quoted context omitted.

> and PMR (memory resource) support. note that this sadly will require your users to use a macOS version that isn't even released yet (or rebuild your own libc++) as Apple ties libc++ to the OS releases. when I see the amount of people around me still on 10.x...

Thank you, good point. It is a small note "Minimum deployment target" at the original article. Seems like features tied to target OS are: PMR, filesystem, to_chars/from_chars and newest atomic-based synchronisation primitives.

std::variant and std::optional also don't work below 10.14

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

#47

Post by menaerus »

ninkendo wrote: post #45
menaerus wrote: post #44

Earlier quoted context omitted.

How else do you imagine different compiler vendors with loath of varying compiler versions work on other Unices?

They define a de facto ABI for their compiler, and once they’re confident enough that the code emitted by their compiler actually works and adheres to it, they take it out of beta and say it’s ready to use. No sooner than that. Not sure what you’re asking here. Remember that supporting C++ features isn’t just about emitting code, it’s about the implementation of libstdc++/libc++ that you have to make sure you don’t p…

Itanium ABI is the de facto ABI standard. It's not developed by a single "compiler" but a collaboration of multiple compiler vendors. It works across basically all Unix/Linux platforms, even Windows. GCC broke the ABI and not "changed it to libstdc++" and that was more than 10 years ago with introduction of C++11 - it's a very rare occassion and exactly the reason why we can have nice and open things in Unices without worrying that software will suddenly break. Mistakes do slip from time to time such as the recent one with LLVM (15) starting to emulate SSE2 when one is not available on the HW but the code makes explicit use of it. Again, such things are rather an exception and my understanding is that Apple chooses quite the opposite strategy - they break their ABI much more often. I see that only as an annoyance which generates unnecessary extra work to keep your code running. I also think that it makes it somewhat impossible to use vanilla clang and mix it with apple-clang binaries. It's a PITA from developer PoV.

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

#48

Post by BlackFingolfin »

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…

OpenCL was created by Apple...

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

#49

Post by ninkendo »

menaerus wrote: post #47
ninkendo wrote: post #45

Earlier quoted context omitted.

They define a de facto ABI for their compiler, and once they’re confident enough that the code emitted by their compiler actually works and adheres to it, they take it out of beta and say it’s ready to use. No sooner than that. Not sure what you’re asking here. Remember that supporting C++ features isn’t just about emitting code, it’s about the implementation of libstdc++/libc++ that you have to make sure you don’t p…

Itanium ABI is the de facto ABI standard. It's not developed by a single "compiler" but a collaboration of multiple compiler vendors. It works across basically all Unix/Linux platforms, even Windows. GCC broke the ABI and not "changed it to libstdc++" and that was more than 10 years ago with introduction of C++11 - it's a very rare occassion and exactly the reason why we can have nice and open things in Unices withou…

I meant “changed libstdc++’s ABI”, not changed to libstdc++.

ABI doesn’t just mean calling conventions defined in things like Itanium’s spec. It also means name mangling, size of structs, and many other things. Think “if I make a shared lib and compile it, and a bunch of programs link to it dynamically at runtime, what changes to the lib can break those programs after the fact, if they don’t recompile?” The answer ends up being a lot. Again, remember that supporting new C++ features means adding things to libc++, which is linked at runtime, so you don’t want to mess it up.

Again, I don’t just mean “change the ABI of arbitrary code emitted by the compiler”, I mean the particular exported symbols in the particular implementation of libc++, which is dynamically linked. If they decide to add one extra field to a struct exported by that lib, then oops, they broke ABI. You don’t want to mess this up and you want it to be stable before letting people use it.

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

#50

Post by menaerus »

ninkendo wrote: post #49
menaerus wrote: post #47

Earlier quoted context omitted.

Itanium ABI is the de facto ABI standard. It's not developed by a single "compiler" but a collaboration of multiple compiler vendors. It works across basically all Unix/Linux platforms, even Windows. GCC broke the ABI and not "changed it to libstdc++" and that was more than 10 years ago with introduction of C++11 - it's a very rare occassion and exactly the reason why we can have nice and open things in Unices withou…

I meant “changed libstdc++’s ABI”, not changed to libstdc++. ABI doesn’t just mean calling conventions defined in things like Itanium’s spec. It also means name mangling, size of structs, and many other things. Think “if I make a shared lib and compile it, and a bunch of programs link to it dynamically at runtime, what changes to the lib can break those programs after the fact, if they don’t recompile?” The answer en…

I think I have a good understanding what ABI is. The point I am trying to make is that the theory you have doesn't add up to the facts - you mention Apple as more cautious around the changes they make but the reality is that they break the ABI much more often than other vendors.
Post reply on HN