3 ms·

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

by 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
  - gpderetta 6y ago
    The ABI break in libstdc++ has nothing to do with templates and it was not done by mistake. The layout of std::string changed to conform to the new standard; exactly the same thing would have happened if std::string was a C POD type, there is no way around that. In fact libstdc++ to this day still has the option to be compiled with the old ABI. There have been other minor ABI breaks, mostly to fix bugs, which affect only a small number of programs. Pure C libraries have exactly the same ABI stability issues caused by changes in layout of structures; to avoid this C libraries expose only opaque pointer sized handles to heap allocated objects. This is similar to C++ libraries only exposing pointers to virtual interfaces, but for high performance libraries, for example containers, this is not considered acceptable.
    - chubot 6y ago
      The point is that data layout is an implementation detail not part of the C++ API, and exposing that through shared libraries isn't a great idea. People do it, but it's a big mess and not particularly well documented. You can write conformant STL implementations that have completely different layouts. But the GNU one no longer had a valid layout, so it had to change. So when you expose libstdc++ as a shared library, you're exposing a bunch of details that aren't part of the C++ standard. If you write it in a header, then you can expect it to break callers via shared library. And templates must be in headers. This is a fundamental language issue. I don't use Rust, but the point is "making a stable ABI" will expose it to these sorts of problems, i.e. implementation details leaking on specific architectures, outside of the language. The projects that care about ABI stability, e.g. sqlite, don't expose layouts. They have only functions and not data in their headers.
      - gpderetta 6y ago
        This thread is getting confusing. Your original point was that for binary compatibility you write against the C ABI. I'm claiming that the C ABI has exactly the same fragile layout limitations and you can use the exact same workarounds in C++ (i.e. only expose pointers or make sure that your layout doesn't change). I'm also claiming that templates are a red herring and have very little to do with ABI.

by chubot 6y ago

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
- gpderetta 6y ago
  The ABI break in libstdc++ has nothing to do with templates and it was not done by mistake. The layout of std::string changed to conform to the new standard; exactly the same thing would have happened if std::string was a C POD type, there is no way around that. In fact libstdc++ to this day still has the option to be compiled with the old ABI. There have been other minor ABI breaks, mostly to fix bugs, which affect only a small number of programs. Pure C libraries have exactly the same ABI stability issues caused by changes in layout of structures; to avoid this C libraries expose only opaque pointer sized handles to heap allocated objects. This is similar to C++ libraries only exposing pointers to virtual interfaces, but for high performance libraries, for example containers, this is not considered acceptable.
  - chubot 6y ago
    The point is that data layout is an implementation detail not part of the C++ API, and exposing that through shared libraries isn't a great idea. People do it, but it's a big mess and not particularly well documented. You can write conformant STL implementations that have completely different layouts. But the GNU one no longer had a valid layout, so it had to change. So when you expose libstdc++ as a shared library, you're exposing a bunch of details that aren't part of the C++ standard. If you write it in a header, then you can expect it to break callers via shared library. And templates must be in headers. This is a fundamental language issue. I don't use Rust, but the point is "making a stable ABI" will expose it to these sorts of problems, i.e. implementation details leaking on specific architectures, outside of the language. The projects that care about ABI stability, e.g. sqlite, don't expose layouts. They have only functions and not data in their headers.
    - gpderetta 6y ago
      This thread is getting confusing. Your original point was that for binary compatibility you write against the C ABI. I'm claiming that the C ABI has exactly the same fragile layout limitations and you can use the exact same workarounds in C++ (i.e. only expose pointers or make sure that your layout doesn't change). I'm also claiming that templates are a red herring and have very little to do with ABI.