3 ms·

On most platforms, if you can interface with C, you can also interface with C++. Usually you have to find the mangled symbol in the C++ binary using a tool like

On most platforms, if you can interface with C, you can also interface with C++. Usually you have to find the mangled symbol in the C++ binary using a tool like nm, and treat it like a C function with whatever ffi you're using. If you are targeting multiple platforms this can get tricky because the mangled C++ symbol will (probably) be different for each platform, which can be solved with a good build system

mhh__ 6y ago
Eek. I've done it but not exactly seamless as implied above! (feels Like using a landmine as a baking scale)
- jhatemyjob 6y ago
  What issues did you run into?
  - mhh__ 6y ago
    I've only ever done it out of curious laziness but it's one of those things where it's theoretically clean enough to do right but if you do it wrong you might be fixing it all day. If something changes downstream or you make a mistake at 9AM you can end up with subtle non-failing garbage everywhere. The only way I would do it and trust it, would be if the binding is generated and tested (separately) automatically, but at that stage why not just write one with a proper ABI.
moonchild 6y ago
Good luck instantiating and using classes if you do it that way. You pretty much have to reimplement the itanium abi in whatever language you're using (hint: if your language doesn't already support it, then even implementing it in assembly would be easier).
jarjoura 6y ago
C++ doesn't have a stable ABI, so if you target a C++ symbol manually like this, as soon as the compiler revs, to say, C++20, the ABI will change and you'll get a linker error. Also, this may work for simple C++ methods, but once you cross over into vtable territory, you're going to be in a world of hurt. Also as far as interoperability, I just don't see a smooth path forward between Swift and C++. Philosophically, much of the C++ code you write ends up compiling away or building specialized generated code at compile time. Anything written in C++17 and newer will also have a lot of constexpr code that generates immutable results baked into the final output. I'd say, wrap your C++ in a simple C API and expose that to Swift (same would apply to Go/Rust or any other language honestly).
- trasz 6y ago
  Stable C++ ABI depends on implementation, it’s not inherent to the language.
- floatboth 6y ago
  Hot take: ABI stability is overrated. How often do you need to relink specifically without recompiling everything? As an OS packager, it's no big deal to rebuild everything depending on a C++ shared library when that library is updated. For self-contained binary distributions, statically linking the C++ library or putting the shared objects together works fine still. vtables are always a pain, but I think the Swift team had some cool ideas about vtables and other dynamic stuff across dynamically linked shared objects.. upd: https://gankra.github.io/blah/swift-abi/ https://gankra.github.io/blah/swift-abi/ this
- jhatemyjob 6y ago
  A good build system would solve those problems. Yes a C wrapper is way easier.

mhh__ 6y ago

Eek. I've done it but not exactly seamless as implied above! (feels Like using a landmine as a baking scale)

jhatemyjob 6y ago
What issues did you run into?
- mhh__ 6y ago
  I've only ever done it out of curious laziness but it's one of those things where it's theoretically clean enough to do right but if you do it wrong you might be fixing it all day. If something changes downstream or you make a mistake at 9AM you can end up with subtle non-failing garbage everywhere. The only way I would do it and trust it, would be if the binding is generated and tested (separately) automatically, but at that stage why not just write one with a proper ABI.

moonchild 6y ago

Good luck instantiating and using classes if you do it that way. You pretty much have to reimplement the itanium abi in whatever language you're using (hint: if your language doesn't already support it, then even implementing it in assembly would be easier).

jarjoura 6y ago

C++ doesn't have a stable ABI, so if you target a C++ symbol manually like this, as soon as the compiler revs, to say, C++20, the ABI will change and you'll get a linker error. Also, this may work for simple C++ methods, but once you cross over into vtable territory, you're going to be in a world of hurt. Also as far as interoperability, I just don't see a smooth path forward between Swift and C++. Philosophically, much of the C++ code you write ends up compiling away or building specialized generated code at compile time. Anything written in C++17 and newer will also have a lot of constexpr code that generates immutable results baked into the final output. I'd say, wrap your C++ in a simple C API and expose that to Swift (same would apply to Go/Rust or any other language honestly).

trasz 6y ago
Stable C++ ABI depends on implementation, it’s not inherent to the language.
floatboth 6y ago
Hot take: ABI stability is overrated. How often do you need to relink specifically without recompiling everything? As an OS packager, it's no big deal to rebuild everything depending on a C++ shared library when that library is updated. For self-contained binary distributions, statically linking the C++ library or putting the shared objects together works fine still. vtables are always a pain, but I think the Swift team had some cool ideas about vtables and other dynamic stuff across dynamically linked shared objects.. upd: https://gankra.github.io/blah/swift-abi/ https://gankra.github.io/blah/swift-abi/ this
jhatemyjob 6y ago
A good build system would solve those problems. Yes a C wrapper is way easier.