4 ms·

C++ has a stable ABI? Do you have pointers on that?

by helge5 8y ago

olliej 8y ago
There are basically two parts to ABI stability. Memory layout, and calling convention. C++ defines the memory layout ABI exactly - two c++ compilers will (theoretically) produce identical struct layouts irrespective of inheritance, virtual vs non virtual classes, etc C++ implementations generally use a calling convention that is stable ABI on each platform, but different platforms may have a different ABI. In the past the MSVC ABI was different from most posix platforms, I’m not sure if that carries through to win64. The easiest way to explain why C++ the language doesn’t prescribe the calling convention ABI is that you may want to compile code on different cpu architectures. There’s no way you could (sensibly) have the same calling convention :)
- IshKebab 8y ago
  There's way more to a stable ABI than that. All of the standard library for example. Try making a binary library that uses `std::string`. It can't really be done - you have to take `const char*` and convert to `std::string` internally. Huge pain for closed-source libraries.
  - olliej 8y ago
    I think you're confusing maintaining ABI stability with at an API level, vs. ABI compatibility at the language level. ABI stability at a language level is for code (replace syntax with your language of choice): class Foo { virtual void bar(); int _i; float _f; bool b; int bitfield : 5; } Should be stable across multiple compilers and versions. This is what swift currently does not have. This is vs. source defined ABI, e.g. class Foo { virtual void bar(); virtual void wibble(); int i; float f; } vs. class Foo { virtual void wibble(); virtual void bar(); float f; int i; } In this example Foo is API stable, and the language ABI means either definition is ABI stable, but as a publicly exposed API it is not ABI stable. C++ defines vtable layout in terms of order of definition (so changing the order of virtual methods is not stable). And you have the source compatible reordering of i and f, which is just as ABI breaking in C++ as it is in a C struct.
    - IshKebab 8y ago
      I'm not confusing it. We weren't talking about API stability at all. The issue isn't Swift's API stability. This is all about ABI - can binaries compiled with one version of the compiler interoperate with binaries compiled with a different version. API stability is easy - C++ has an extremely stable API. Swift is pretty stable apparently.
      - olliej 8y ago
        Ok, here's an example API: SomeLibrary.h: class Foo { virtual void bar(); virtual ~Foo(); }; The library is compiled into SomeLibrary.dll,dylib,so or what have you. Your program uses this: void my_cool_function(Foo* foo) { foo->bar(); } Later on the library makes a change, and adds a new virtual method wibble(). The API is stable -- they haven't removed Foo::bar, and they haven't changed its parameters or return type. But this API change can break the library ABI if it declared the new virtual method in the wrong part of the class, because vtable ordering is defined as being order of declaration. So there are two aspects of ABI compatibility. First, does a given API result in the same ABI irrespective of what compiler version it uses. The second is, given that your language is ABI stable, are your changes to the API also ABI stable. C++ is notoriously bad at this, because of foot guns like vtable ordering, changes to binary layout of superclasses, etc. Swift is at least in existing versions even less stable, where you're not necessarily guaranteed that a single API will get the same ABI depending on what things it is compiled with, and certainly not through even minor compiler version changes - let alone actual language version changes.

C++ has a stable ABI? Do you have pointers on that?

by helge5 8y ago

C++ has a stable ABI? Do you have pointers on that?

There are basically two parts to ABI stability. Memory layout, and calling convention. C++ defines the memory layout ABI exactly - two c++ compilers will (theoretically) produce identical struct layouts irrespective of inheritance, virtual vs non virtual classes, etc C++ implementations generally use a calling convention that is stable ABI on each platform, but different platforms may have a different ABI. In the past the MSVC ABI was different from most posix platforms, I’m not sure if that carries through to win64. The easiest way to explain why C++ the language doesn’t prescribe the calling convention ABI is that you may want to compile code on different cpu architectures. There’s no way you could (sensibly) have the same calling convention :)

IshKebab 8y ago
There's way more to a stable ABI than that. All of the standard library for example. Try making a binary library that uses `std::string`. It can't really be done - you have to take `const char*` and convert to `std::string` internally. Huge pain for closed-source libraries.
- olliej 8y ago
  I think you're confusing maintaining ABI stability with at an API level, vs. ABI compatibility at the language level. ABI stability at a language level is for code (replace syntax with your language of choice): class Foo { virtual void bar(); int _i; float _f; bool b; int bitfield : 5; } Should be stable across multiple compilers and versions. This is what swift currently does not have. This is vs. source defined ABI, e.g. class Foo { virtual void bar(); virtual void wibble(); int i; float f; } vs. class Foo { virtual void wibble(); virtual void bar(); float f; int i; } In this example Foo is API stable, and the language ABI means either definition is ABI stable, but as a publicly exposed API it is not ABI stable. C++ defines vtable layout in terms of order of definition (so changing the order of virtual methods is not stable). And you have the source compatible reordering of i and f, which is just as ABI breaking in C++ as it is in a C struct.
  - IshKebab 8y ago
    I'm not confusing it. We weren't talking about API stability at all. The issue isn't Swift's API stability. This is all about ABI - can binaries compiled with one version of the compiler interoperate with binaries compiled with a different version. API stability is easy - C++ has an extremely stable API. Swift is pretty stable apparently.
    - olliej 8y ago
      Ok, here's an example API: SomeLibrary.h: class Foo { virtual void bar(); virtual ~Foo(); }; The library is compiled into SomeLibrary.dll,dylib,so or what have you. Your program uses this: void my_cool_function(Foo* foo) { foo->bar(); } Later on the library makes a change, and adds a new virtual method wibble(). The API is stable -- they haven't removed Foo::bar, and they haven't changed its parameters or return type. But this API change can break the library ABI if it declared the new virtual method in the wrong part of the class, because vtable ordering is defined as being order of declaration. So there are two aspects of ABI compatibility. First, does a given API result in the same ABI irrespective of what compiler version it uses. The second is, given that your language is ABI stable, are your changes to the API also ABI stable. C++ is notoriously bad at this, because of foot guns like vtable ordering, changes to binary layout of superclasses, etc. Swift is at least in existing versions even less stable, where you're not necessarily guaranteed that a single API will get the same ABI depending on what things it is compiled with, and certainly not through even minor compiler version changes - let alone actual language version changes.