4 ms·

If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI. Likewise Rust users should write to the C ABI for stabled shared l

by chubot 6y ago

If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI. Likewise Rust users should write to the C ABI for stabled shared libraries. (I believe there are a bunch of mechanisms to do that, though I'm not really a Rust user) For example look at what KDE does: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B https://community.kde.org/Policies/Binary_Compatibility_Issu... Yes, you have to do a lot of extra work. That's working as intended. It's sort of an oxymoron to expect to use every C++ or Rust feature in your user-facing ABI and have it be stable. They are incredibly rich languages, with drastically different notions of "function" than C has (let alone other constructs like data layout)

steveklabnik 6y ago
(There are mechanisms to do this, yes)
IshKebab 6y ago
Yes you should do that now but only because Rust doesn't have a stable ABI. If/when it does then there's nothing wrong with distributing shared libraries using the Rust ABI, just like there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff. The C++ ABIs are pretty stable.
- chubot 6y ago
  there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff That's the whole point of the KDE doc I linked. It's not a reasonable strategy to use unrestricted C++, just like it's not a reasonable strategy to use unrestricted Rust. You actually have to design an ABI, not just rely on the compiler to do it for you. I thought there was a GNOME doc too, but I couldn't find it. The point remains: there are lots of things in C++ that people who care about stability don't use at their ABI boundaries.
nicoburns 6y ago
There's also the possibility of an opt-in stable ABI (using the `repr` mechanism). I personally really like the idea of there being an opt-in cross-language ABI at a higher level (or supporting more use cases) than the C ABI (which is quite limiting).
- pjmlp 6y ago
  For example, COM/UWP on Windows, Binder on Android.
gpderetta 6y ago
I don't understand what is your point. The KDE example you have linked shows that you can in fact guarantee a stable C++ ABI (although it requires a lot of care). The fact that they go through all the trouble is a hint that a C ABI is in fact too restrictive and not expressive enough for a large framework like KDE. Specifically KDE relies (among other things) on the ABI stability of the layout of virtual tables which is certainly not part of the C ABI.
- chubot 6y ago
  That's fair, there is a middle ground between C and C++. My point is that you can't expect the compiler to do everything for you in terms of creating a stable ABI for shared libraries. I think a lot of people are under the impression that this is purely a compiler feature. What I expect to happen is that rather than "Rust gets a stable ABI" it will be "Rust very gradually builds upon the C ABI for selected features". Most C++ libraries have templates in their signatures these days for efficiency, and Rust has a similar flavor (monomorphization). I think there is a fundamental tradeoff there between stability and performance, and both languages have a heavy emphasis on the latter. I could be missing something as I certainly don't know all the details of the C++ ABI.
  - gpderetta 6y ago
    Even with templates you can still keep the ABI stable, se for example libstdc++. Which is not surprising as they compile down to the equivalent C code.
    - chubot 6y ago
      I think your example is better evidence for my view. I remember this issue being mentioned in a CppCon talk: C++ 11 broke the ABI for STL (for efficiency as far as I remember), and the binary interface to libstdc++ changed as a result: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... So the ABI can leak implementation details in nontrivial ways that library authors usually don't consider. It's better to have something explicit in the code, e.g. under extern "C". The point is not that making a stable API for every language feature is impossible; just that it's hard, fragile, and maybe not be worth the effort. If you really want stability, then use fewer features more like C. There is probably some middle ground that's richer, but templates are known to cause problems. Also see the release history here: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

by chubot 6y ago

steveklabnik 6y ago

(There are mechanisms to do this, yes)

IshKebab 6y ago

Yes you should do that now but only because Rust doesn't have a stable ABI. If/when it does then there's nothing wrong with distributing shared libraries using the Rust ABI, just like there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff. The C++ ABIs are pretty stable.

chubot 6y ago
there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff That's the whole point of the KDE doc I linked. It's not a reasonable strategy to use unrestricted C++, just like it's not a reasonable strategy to use unrestricted Rust. You actually have to design an ABI, not just rely on the compiler to do it for you. I thought there was a GNOME doc too, but I couldn't find it. The point remains: there are lots of things in C++ that people who care about stability don't use at their ABI boundaries.

nicoburns 6y ago

There's also the possibility of an opt-in stable ABI (using the `repr` mechanism). I personally really like the idea of there being an opt-in cross-language ABI at a higher level (or supporting more use cases) than the C ABI (which is quite limiting).

pjmlp 6y ago
For example, COM/UWP on Windows, Binder on Android.

gpderetta 6y ago

I don't understand what is your point. The KDE example you have linked shows that you can in fact guarantee a stable C++ ABI (although it requires a lot of care). The fact that they go through all the trouble is a hint that a C ABI is in fact too restrictive and not expressive enough for a large framework like KDE. Specifically KDE relies (among other things) on the ABI stability of the layout of virtual tables which is certainly not part of the C ABI.

chubot 6y ago
That's fair, there is a middle ground between C and C++. My point is that you can't expect the compiler to do everything for you in terms of creating a stable ABI for shared libraries. I think a lot of people are under the impression that this is purely a compiler feature. What I expect to happen is that rather than "Rust gets a stable ABI" it will be "Rust very gradually builds upon the C ABI for selected features". Most C++ libraries have templates in their signatures these days for efficiency, and Rust has a similar flavor (monomorphization). I think there is a fundamental tradeoff there between stability and performance, and both languages have a heavy emphasis on the latter. I could be missing something as I certainly don't know all the details of the C++ ABI.
- gpderetta 6y ago
  Even with templates you can still keep the ABI stable, se for example libstdc++. Which is not surprising as they compile down to the equivalent C code.
  - chubot 6y ago
    I think your example is better evidence for my view. I remember this issue being mentioned in a CppCon talk: C++ 11 broke the ABI for STL (for efficiency as far as I remember), and the binary interface to libstdc++ changed as a result: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... So the ABI can leak implementation details in nontrivial ways that library authors usually don't consider. It's better to have something explicit in the code, e.g. under extern "C". The point is not that making a stable API for every language feature is impossible; just that it's hard, fragile, and maybe not be worth the effort. If you really want stability, then use fewer features more like C. There is probably some middle ground that's richer, but templates are known to cause problems. Also see the release history here: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html