4 ms·

I'd say this is misleading, or only technically correct (the best kind of correct). Calling conventions are only the first step. For interop to be useful in pra

I'd say this is misleading, or only technically correct (the best kind of correct). Calling conventions are only the first step. For interop to be useful in practice -- to be able pass more interesting C++ types than integers -- you also need your standard library types to be (and remain) compatible[1]. This currently isn't guaranteed even across versions of the same compiler. [1] Herb Sutter's C++ ABI effort was supposed to solve exactly this, but unfortunately never went anywhere. The proposal document pinpoints the problem very well in my opinion: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n40...

rossmohax 4y ago
Do you have exmoles to support claim that there is no compatibility between versions of the same compiler? your linked pdf is from 2014, exact time when compilers stopped breaking things. AFAIK MSVC compilers explicitly guarantee ABI compatibility since 2015 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-... as for other platforms, all compilers adhere to Itanium ABI and didnt introduce breaking changes for many years now. Standard libraries, libc++ has explicit ABI guarantee as well (https://libcxx.llvm.org/DesignDocs/ABIVersioning.html https://libcxx.llvm.org/DesignDocs/ABIVersioning.html). Libstdc++ uses symbol versioning and only nasty thing happened to it was problem with std::string CoW decade ago, but even that was done neatly and in compatible manner https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...
- quietbritishjim 4y ago
  MSVC guarantee ABI compatibility between different versions of MSVC, not with the inter-compiler ABI mentioned by parent comment. But the parent comment's point is that, even for those different compilers that do follow that inter-compiler ABI, the standard libraries have different binary layouts from other compilers. Your final two links show that GCC and LLVM standard libraries each have the same binary layout as itself between different versions, but not as the other.
gpderetta 4y ago
Because the C++ ABI is fragile, in practice you need a blessed library ABI for the standard library. On linux for example it is libstdc++ which has been stable for almost 20 years (yes, there was a brakeage around c++11, but there are compatible shims for backward compat). Clang and the intel compiler can compile against libstdc++.
- not2b 4y ago
  No, this isn't because the C++ ABI is fragile, but because the standard library wasn't part of its scope. It only covers the layout of objects and how parameters are passed to function calls, and does not cover the implementation details of standard classes. There are competing, incompatible standard libraries.
  - gpderetta 4y ago
    well, the ABI doc says: We have not attempted to constrain the interface [of the standard library] at this level, because we do not consider doing so feasible at this time So it wasn't necessarily out of scope, it was just hard to do. I think the reason they don't consider it feasible, is because the C++ ABI would constrain the implementation significantly and there was too much divergence already.

rossmohax 4y ago

Do you have exmoles to support claim that there is no compatibility between versions of the same compiler? your linked pdf is from 2014, exact time when compilers stopped breaking things. AFAIK MSVC compilers explicitly guarantee ABI compatibility since 2015 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-... as for other platforms, all compilers adhere to Itanium ABI and didnt introduce breaking changes for many years now. Standard libraries, libc++ has explicit ABI guarantee as well (https://libcxx.llvm.org/DesignDocs/ABIVersioning.html https://libcxx.llvm.org/DesignDocs/ABIVersioning.html). Libstdc++ uses symbol versioning and only nasty thing happened to it was problem with std::string CoW decade ago, but even that was done neatly and in compatible manner https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...

quietbritishjim 4y ago
MSVC guarantee ABI compatibility between different versions of MSVC, not with the inter-compiler ABI mentioned by parent comment. But the parent comment's point is that, even for those different compilers that do follow that inter-compiler ABI, the standard libraries have different binary layouts from other compilers. Your final two links show that GCC and LLVM standard libraries each have the same binary layout as itself between different versions, but not as the other.

gpderetta 4y ago

Because the C++ ABI is fragile, in practice you need a blessed library ABI for the standard library. On linux for example it is libstdc++ which has been stable for almost 20 years (yes, there was a brakeage around c++11, but there are compatible shims for backward compat). Clang and the intel compiler can compile against libstdc++.

not2b 4y ago
No, this isn't because the C++ ABI is fragile, but because the standard library wasn't part of its scope. It only covers the layout of objects and how parameters are passed to function calls, and does not cover the implementation details of standard classes. There are competing, incompatible standard libraries.
- gpderetta 4y ago
  well, the ABI doc says: We have not attempted to constrain the interface [of the standard library] at this level, because we do not consider doing so feasible at this time So it wasn't necessarily out of scope, it was just hard to do. I think the reason they don't consider it feasible, is because the C++ ABI would constrain the implementation significantly and there was too much divergence already.