3 ms·

This just lists what they do support, not what they leave out compared to the free alternatives. Here's a better chart -- look at all that red in the Apple cla

by gumby 3y ago

This just lists what they do support, not what they leave out compared to the free alternatives. Here's a better chart -- look at all that red in the Apple clang column: https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support I don't understand why they deviate so much from mainstream clang. I think they'd be better off being closer to the trunk. TBH I don't really understand why they have their own tree at all.

saurik 3y ago
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 isn't far off of upstream clang and yet they also often are shipping a slightly older version... it just doesn't warrant its own column as they expose the underlying clang version number, while Apple does this really really annoying thing where the version number of clang is hacked to report a version number based on the Xcode release cycle (so the moral equivalent would be if Android NDK r25c modified clang 16 to report version 25... they don't do that, so they don't really need to be treated as their own compiler ever.)
- pjmlp 3y ago
  Unless it changed, tracking down what Android NDK ships is even worse, tracking down git hash codes to guess which clang was imported into NDK rXX.
  - pjmlp 3y ago
    Update to myself, not only it hasn't had a release since July 2022, we are suppose to track down which LLVM 14 release, the hash clang-r450784d actually maps to, like always. https://developer.android.com/ndk/downloads https://developer.android.com/ndk/downloads
- Someone 3y ago
  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.
  - _eojb 3y ago
    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.
    - Longhanks 3y ago
      > 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).
      - ninepoints 3y ago
        Yes I hack on llvm and clang. Where can I submit a PR to Apple Clang?
    - sesuximo 3y ago
      You can absolutely use a different compiler as an apple dev. Just might be a touch tougher to set up a non-standard build
      - watersb 3y ago
        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.
aseipp 3y ago
They have definitely in the past added features that they later released as part of product launches and then upstreamed, e.g. ARM64 backend or more recently -fbounds-checks (which I think will be in the new Xcode?) Other things I don't think they ever tried to upstream e.g. I think watchOS bitcode might have been special. In the end it's basically the same reason anyone maintains a fork or a set of patches; better integration and prioritization of the things you need for your products and more control over risk, etc. It would always be nice to slim the differences and get new releases faster though, of course.
trebel 3y ago
This wiki seems somewhat out of date. For example OP lists support for P2362R3, but the wiki has that as red.
- gumby 3y ago
  cppreference is indeed a wiki so you can update it if you’d like. Usually the compiler maintainers do.
pjmlp 3y ago
They only need enough for Swift, Objective-C(++) and Metal Shading Language implementations, alongside IO and Driver Kit, the key places where Apple's ecosystem makes use of C++. Then they used to have the integration of blocks (C extension for lambdas) into the respective frameworks, and their own bitcode format was more stable than LLVM bitcode (deprecated now, most likely fed up with the bitcode fork).

by gumby 3y ago

saurik 3y ago

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 isn't far off of upstream clang and yet they also often are shipping a slightly older version... it just doesn't warrant its own column as they expose the underlying clang version number, while Apple does this really really annoying thing where the version number of clang is hacked to report a version number based on the Xcode release cycle (so the moral equivalent would be if Android NDK r25c modified clang 16 to report version 25... they don't do that, so they don't really need to be treated as their own compiler ever.)

pjmlp 3y ago
Unless it changed, tracking down what Android NDK ships is even worse, tracking down git hash codes to guess which clang was imported into NDK rXX.
- pjmlp 3y ago
  Update to myself, not only it hasn't had a release since July 2022, we are suppose to track down which LLVM 14 release, the hash clang-r450784d actually maps to, like always. https://developer.android.com/ndk/downloads https://developer.android.com/ndk/downloads
Someone 3y ago
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.
- _eojb 3y ago
  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.
  - Longhanks 3y ago
    > 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).
    - ninepoints 3y ago
      Yes I hack on llvm and clang. Where can I submit a PR to Apple Clang?
  - sesuximo 3y ago
    You can absolutely use a different compiler as an apple dev. Just might be a touch tougher to set up a non-standard build
    - watersb 3y ago
      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.

aseipp 3y ago

They have definitely in the past added features that they later released as part of product launches and then upstreamed, e.g. ARM64 backend or more recently -fbounds-checks (which I think will be in the new Xcode?) Other things I don't think they ever tried to upstream e.g. I think watchOS bitcode might have been special. In the end it's basically the same reason anyone maintains a fork or a set of patches; better integration and prioritization of the things you need for your products and more control over risk, etc. It would always be nice to slim the differences and get new releases faster though, of course.

trebel 3y ago

This wiki seems somewhat out of date. For example OP lists support for P2362R3, but the wiki has that as red.

gumby 3y ago
cppreference is indeed a wiki so you can update it if you’d like. Usually the compiler maintainers do.

pjmlp 3y ago

They only need enough for Swift, Objective-C(++) and Metal Shading Language implementations, alongside IO and Driver Kit, the key places where Apple's ecosystem makes use of C++. Then they used to have the integration of blocks (C extension for lambdas) into the respective frameworks, and their own bitcode format was more stable than LLVM bitcode (deprecated now, most likely fed up with the bitcode fork).