I'm mainly a C++ guy. As C++ lacks an official ABI I always use a COM-like approach for component designs that support more than one compiler.
Recently I came across the question whether Objective-C would be a replacement for the COM-like approach. Obviously for Objective-C to be a replacement one would need a stable ABI, therefor I'd like to know if a stable ABI for Objective-C exists (on all major OSes [OSX, GNU/Linux, Windows]) and how easy it would be to use Objective-C(++) as "glue" between components created by different compilers.
EDIT: As Nikolai Ruhe pointed out a short description of COM may be helpful. COM is essentially a "binary standard" that allows mixing binarys of different compilers (and in a variety of languages). The vehicle of COM are interfaces, which define methods (which map to C++'s virtual functions). Components implement a at least one interfaces and are distributed as DLLs. They can be located anywhere on the system (the position is specified in the Registry) and can be loaded by any COM-client via the ID of the interface they implement.
What Is ABI Stability? ABI stability means locking down the ABI to the point that future compiler versions can produce binaries conforming to the stable ABI. Once an ABI is stable, it tends to persist for the rest of the platform's lifetime due to ever-increasing mutual dependencies.
C does not have a standard ABI.
ABI stability allows the Swift Standard Library to be included at runtime within any operating system, including Linux and Windows (eventually). In lay-terms, this means if an app or service is written in Swift, the OS can support it without workarounds.
Compiled Rust code doesn't have a stable ABI (application binary interface). So, we can't have shared libraries in the traditional fashion of Linux distributions. Also Rust bundles its entire standard library with every binary it compiles, which makes Rust-built libraries huge.
I can only speak for Apple's implementation, as I have no experience with the GNU or other ports.
Objective-C relies on C's ABI for the most part (like function calls and memory layout of structs).
It's own ABI underwent a couple of changes in Apple's implementation, like non-fragile instance variables introduced with the "Modern Runtime", introduction of properties, faster exception handling, garbage collection, __weak
support for ARC.
Some of the changes were backwards compatible, some not. But since the whole system and frameworks are provided by Apple and the changes were usually introduced with other non-compatible changes (switch to Intel, and LP64) this was without consequences to users.
Edit: One thing you should have in mind is that Objective-C does not only rely on a fixed ABI but also on a compatible runtime. That's one more headache to care about for your purpose.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With