4 ms·

Apple Clang is already a completely different beast than upstream, right? At least the version numbers are nonsensical unnecessarily complicating feature suppor

by cozzyd 4y ago

Apple Clang is already a completely different beast than upstream, right? At least the version numbers are nonsensical unnecessarily complicating feature support checks in my experience as someone who doesn't own any Macs but writes software that others insist on trying to compile on a Mac...

pjmlp 4y ago
Yes, hence having its own column on cppreference, or a special flavour of bitcode for watchOS. In what concerns Apple, I think they mostly care about the C++ support needed to keep LLVM going, the C++14 based dialect for Metal Shading Language, and the subset used across IO and DriverKit. For everything else there is Objective-C and Swift. Then Google apparently drop off clang after the ABI break votes didn't went the way they wanted, so they are now focusing on Abseil, and their style guide is anyway quite restrictive. So now we are in this ironic situation, that VC++ from all compilers is the one with best C++20 support, closely followed by GCC, and then there is clang and the other lesser known ones still lagging in C++17 and earlier.
- lenkite 4y ago
  Yep, the perma-frozen ABI decision sounded the death-knell for C++. Basically the committee committed collective hara-kiri with that decision. Thou Shalt Not Progress! It's so extraordinarily, mind-bogglingly stupid. But I guess it is time for the ageing C++ queen to pushed out of the mortal coil and let Princess Rust grab her long-overdue system crown.
  - cozzyd 4y ago
    I don't know, ABI changes are super annoying.
  - pjmlp 4y ago
    Princess Rust has no proper throne on the kingdom of binary libraries.
    - tialaramex 4y ago
      Without ABI change C++ is trapped forever with bad decisions. In some cases these are decisions which were bad twenty years ago and are still bad today but should be fixed, in other cases these are decisions which were probably the right call twenty years ago but now you'd choose differently. Did you know on MSVC a std::mutex is so huge it needs more than one cache line ? Obviously Microsoft aren't stupid, they know how to fix that... but it would change the ABI so they can't touch it. And so the Zero Cost Abstraction promise "Don't pay more than it would cost if you did it yourself" becomes "Eh, just do it yourself" everywhere - C++ programmers learn to hand roll all the basic stuff they need, because ABI stability has ensured the standard library mechanisms are slow, or bloated, or both.
      - pjmlp 4y ago
        Doesn't matter, binary libraries are a big deal for many businesses, regardless of ABI constraints in C and C++ languages and compilers. Either Rust wants to play on that field, or it doesn't. Microsoft has broken their ABI plenty of times, and VS vNext might be when the next break will take place, which was initially planned for VS 2022. Bashing C and C++ ABI issues on HN will do very little for those businesses to adopt source code distributions.
        zozbot234 4y ago
        You can write and use binary libraries in Rust, you're just restricted to using the stable C ABI to interface across separately-built components. Spoiler: You'll want to do this anyway, because it's required for any sort of C-compatible FFI regardless of language.
        pjmlp 4y ago
        Nope, Windows C++ compilers have supported DLLs since Windows 16 bit days. Some famous C++ frameworks that ship as binaries are OWL, VCL, FireMonkey, MFC, ATL, WinUI. And WinRT has improved upon classical COM ABI to provide even more data types. On Windows there is a component market selling libraries for those ecosystems. Then we have middleware vendors for game consoles as well. Maybe this isn't a market Rust community cares about and that is fine.
- fweimer 4y ago
  On the GCC side, there are no plans to stop supporting building applications using Clang and libstdc++ (that is, using the libstdc++ installed headers and the GCC-built libraries/shared objects). Therefore, a question mark next to libc++ doesn't necessarily threaten the long-term viability of Clang as a C++ compiler. (I assume your Abseil comment is actually about libc++.)
  - pjmlp 4y ago
    My Abseil comment is about where Google now rather sees their employees spending time on C++ libraries for them. At least from the comments I sometimes see flying by on Reddit.

by cozzyd 4y ago

pjmlp 4y ago

Yes, hence having its own column on cppreference, or a special flavour of bitcode for watchOS. In what concerns Apple, I think they mostly care about the C++ support needed to keep LLVM going, the C++14 based dialect for Metal Shading Language, and the subset used across IO and DriverKit. For everything else there is Objective-C and Swift. Then Google apparently drop off clang after the ABI break votes didn't went the way they wanted, so they are now focusing on Abseil, and their style guide is anyway quite restrictive. So now we are in this ironic situation, that VC++ from all compilers is the one with best C++20 support, closely followed by GCC, and then there is clang and the other lesser known ones still lagging in C++17 and earlier.

lenkite 4y ago
Yep, the perma-frozen ABI decision sounded the death-knell for C++. Basically the committee committed collective hara-kiri with that decision. Thou Shalt Not Progress! It's so extraordinarily, mind-bogglingly stupid. But I guess it is time for the ageing C++ queen to pushed out of the mortal coil and let Princess Rust grab her long-overdue system crown.
- cozzyd 4y ago
  I don't know, ABI changes are super annoying.
- pjmlp 4y ago
  Princess Rust has no proper throne on the kingdom of binary libraries.
  - tialaramex 4y ago
    Without ABI change C++ is trapped forever with bad decisions. In some cases these are decisions which were bad twenty years ago and are still bad today but should be fixed, in other cases these are decisions which were probably the right call twenty years ago but now you'd choose differently. Did you know on MSVC a std::mutex is so huge it needs more than one cache line ? Obviously Microsoft aren't stupid, they know how to fix that... but it would change the ABI so they can't touch it. And so the Zero Cost Abstraction promise "Don't pay more than it would cost if you did it yourself" becomes "Eh, just do it yourself" everywhere - C++ programmers learn to hand roll all the basic stuff they need, because ABI stability has ensured the standard library mechanisms are slow, or bloated, or both.
    - pjmlp 4y ago
      Doesn't matter, binary libraries are a big deal for many businesses, regardless of ABI constraints in C and C++ languages and compilers. Either Rust wants to play on that field, or it doesn't. Microsoft has broken their ABI plenty of times, and VS vNext might be when the next break will take place, which was initially planned for VS 2022. Bashing C and C++ ABI issues on HN will do very little for those businesses to adopt source code distributions.
      - zozbot234 4y ago
        You can write and use binary libraries in Rust, you're just restricted to using the stable C ABI to interface across separately-built components. Spoiler: You'll want to do this anyway, because it's required for any sort of C-compatible FFI regardless of language.
        pjmlp 4y ago
        Nope, Windows C++ compilers have supported DLLs since Windows 16 bit days. Some famous C++ frameworks that ship as binaries are OWL, VCL, FireMonkey, MFC, ATL, WinUI. And WinRT has improved upon classical COM ABI to provide even more data types. On Windows there is a component market selling libraries for those ecosystems. Then we have middleware vendors for game consoles as well. Maybe this isn't a market Rust community cares about and that is fine.
fweimer 4y ago
On the GCC side, there are no plans to stop supporting building applications using Clang and libstdc++ (that is, using the libstdc++ installed headers and the GCC-built libraries/shared objects). Therefore, a question mark next to libc++ doesn't necessarily threaten the long-term viability of Clang as a C++ compiler. (I assume your Abseil comment is actually about libc++.)
- pjmlp 4y ago
  My Abseil comment is about where Google now rather sees their employees spending time on C++ libraries for them. At least from the comments I sometimes see flying by on Reddit.