No std::format? Or am I just not searching for the right thing?
No clue what it will appear as once it is there, but I'm not seeing it listed as Apple supported in the cppreference table either. It is listed as "Text Formatting" there.
Overview of C++ language support in Apple Clang
31–40 of 50 posts
Re: Overview of C++ language support in Apple Clang
#32Earlier quoted context omitted.
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.
OpenMP and GCD are very different in some ways, yet very similar in others. Both provide threadpool-based parallelism, and both provided "managed" parallelism well before C and C++ gained standardized parallelism via std::async/std::future/std::thread. If you want vendor-supported threadpool parallelism on MacOS, GCD was the singular answer for years. They aren't exactly compatible, but neither are Cilk or TBB to OpenMP, yet all of these approaches can be used to perform a similar subset of parallelized operations.
libdispatch is open source, and available on Linux, but I can't see any reason to use it versus the alternatives of TBB and OpenMP, unless you were trying to port an application/library originally written for MacOS/iOS.
Re: Overview of C++ language support in Apple Clang
#33Finally, it's great that Apple added library support for ranges and PMR (memory resource) support. Currently, with a stable Xcode, you are living with clang 14. Link [1] is helpful for matching clang versions and placing preprocessor guards. Many new features (like pmr) were available in 'experimental' headers but not implemented in libc++ or any experimental library that lies nearby 'libc++'. Usually, I expect an ex…
> 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...
Re: Overview of C++ language support in Apple Clang
#34Earlier quoted context omitted.
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.
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.
Re: Overview of C++ language support in Apple Clang
#35> De-deprecating volatile compound operations. Thank goodness. Those deprecatios are a pain in the butt.
I kind of understand that for embedded. Where do you need to use it when targeting MacOS?
Re: Overview of C++ language support in Apple Clang
#36TIL about P2327R1 (De-deprecating volatile compound operations) [0] and the earlier (P1152) deprecation of volatile compound expressions due to those giving the incorrect appearance of atomicity. I'm shaking my head. The `volatile` keyword has a very specific and useful meaning, and P1152 should never have happened.
[0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...
Re: Overview of C++ language support in Apple Clang
#37Earlier 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…
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.
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.
Re: Overview of C++ language support in Apple Clang
#38Earlier quoted context omitted.
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.
This isn't necessarily a free software versus open source issue. Apple could have just as easily continued to ship a GCC version with OpenMP disabled. Sure you could build your own with-OpenMP GCC from source, just like you can build MacOS-compatible upstream Clang from source now. But third-party dev tools will always be a pain and an additional barrier to use.
There are a couple of notable examples of major software shipping OpenMP-using code on MacOS, namely R and Matlab, but the structure of these projects means that few of their users have to encounter the complexity of getting an OpenMP-supporting toolchain working. Not so easy for a library author where nearly all of your users will need to use a special toolchain.
Re: Overview of C++ language support in Apple Clang
#39Finally, it's great that Apple added library support for ranges and PMR (memory resource) support. Currently, with a stable Xcode, you are living with clang 14. Link [1] is helpful for matching clang versions and placing preprocessor guards. Many new features (like pmr) were available in 'experimental' headers but not implemented in libc++ or any experimental library that lies nearby 'libc++'. Usually, I expect an ex…
> 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.
Re: Overview of C++ language support in Apple Clang
#40Earlier quoted context omitted.
> 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.
This isn't necessarily a free software versus open source issue. Apple could have just as easily continued to ship a GCC version with OpenMP disabled. Sure you could build your own with-OpenMP GCC from source, just like you can build MacOS-compatible upstream Clang from source now. But third-party dev tools will always be a pain and an additional barrier to use. There are a couple of notable examples of major softwar…
> Apple could have just as easily continued to ship a GCC version with OpenMP disabled.
Sure, and one of their users could have distributed a version that put it back in.