29 ms·

Mixing Swift and C++

84 points by oumua_don17 3y ago

ashvardanian 3y ago
On a related topic of hybrid Swift and C++ tooling - has anyone used Doxygen/Sphinx to generate HML docs for modern Swift, similar to how people do it for pure C++ projects?
- dagmx 3y ago
  Swift does have docc that does the same https://swift.org/blog/swift-docc/ https://swift.org/blog/swift-docc/ I’ve never had good luck getting documentation working cross language and so I use docc for Swift, doxygen for C++, rustdoc for Rust and Sphinx for Python. Then I just link between them if a project uses more than one language
  - ashvardanian 3y ago
    Sure, but how do you style and host those docs? Can you style them identically? We use a combo of Furo + Sphinx + Doxygen for C/C++, Python, JavaScript, Java here: https://unum-cloud.github.io/docs/usearch https://unum-cloud.github.io/docs/usearch For ObjC, Swift, Rust, and other languages we couldn’t make it work for now.
    - dagmx 3y ago
      I gave up on trying to style them exactly the same. I manage my own CSS that brings them closer but they all behave so differently. I wrote my own hosting solution to host multiple doc types and switch between versions. Unfortunately I can’t share it since it’s for work but it wasn’t too hard. Though I wish there was a good off the shelf solution here.
      - ashvardanian 3y ago
        Similar state here. It’s so frustrating. Thx!
Dig1t 3y ago
I have not yet understood who this is for. Are there many developers who have Mac apps written in C++ that want to move their code base to Swift? If so how do they do UI? I thought you needed to at least use Objective-C to use Apple GUI frameworks. Or is there some set of libraries in C++ that are crucial to bring into Swift?
- zapzupnz 3y ago
  You don’t need to use Objective-C to use the GUI frameworks, haven’t had to for nearly a decade if I’ve been using Swift since then. Now with more and more pure Swift apps, the C++ interop is more direct than having to go through Swift’s existing C interop.
chunkyguy 3y ago
> A C++ class or structure becomes a standalone type in Swift. Its relationship with base C++ classes is not preserved in Swift. C++ `class Fern: public Plant` becomes two different types in Swift `struct Plant` and `struct Fern`, how is this supposed to help anyone? https://www.swift.org/documentation/cxx-interop/#accessing-inherited-members-from-swift https://www.swift.org/documentation/cxx-interop/#accessing-i...
- dagmx 3y ago
  It still allows you to use them for interop. The only functionality that would be impaired is checking for inheritance with an `as?` type check/conform.
  - fooker 3y ago
    No, this blocks a fundamental concept of OOP: Liskov Substitution Principle. The idea is that you should be able to use a derived object anywhere the base one is required.
    - dagmx 3y ago
      It impairs that principle, yes. But it doesn’t block similar patterns that give you similar end results. Swift has very flexible generics programming and type abstraction that still lets you use it with a little extra work. Yes, it won’t be as ergonomic as the ideal, but it’s better than many binding solutions from C++ to compiled languages, while providing most of the usability. Plus the footnote says that they plan to resolve this in future Swift versions.
    - dwaite 3y ago
      It does not import the relationship, but you can still model it via protocols.
- mgaunard 3y ago
  Interop isn't magic. It can't make the C++ model transparently compatible with that of Swift when the two languages deviate.
kubb 3y ago
C++ interop is impressive, and notoriously hard to get right. This seems like it would be able to cover a lot of APIs. Swift and C# are the well-designed languages I'd rather use at my work instead of Go. It's a real shame both are effectively locked into a specific platform. You can really tell that they had years of attention and careful design by experts in PL poured into them. Go seems like an amateur hobby project in comparison.
- wilg 3y ago
  I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform. It's no problem to run Swift on Linux or Windows. Of course, Apple's UI libraries aren't cross-platform. And they're putting a bunch of effort into making it better for servers and such. I wish more people realized how usable it is cross-platform, I think this is a misconception that hampers Swift adoption. Swift is definitely my favorite programming language from a language standpoint. I really like the way Swift works. It's safe, concise without being terse, and easy to extend. Sure, some people can argue there's some "bloat", but I think that's inevitable in a language that was designed to immediately be usable within Apple's existing APIs and frameworks. There's going to be complexity with Objective-C interop, C++ interop, etc. But that stuff is necessary for Swift to be usable for big projects. And I think Apple has done quite a good job of evolving Swift to be cleaner, clearer, more ergonomic, etc. I'm very excited that there's a lot of effort behind an open-source, cross-platform type-safe, compiled language that also prioritizes ergonomic high-level programming.
  - t0ps0il 3y ago
    > I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform I think the key word in OPs comment is "effectively". The tools for building cross platform Swift exist and work in various levels but they aren't at the point where you would want to choose Swift over existing cross platform tools.
    - wilg 3y ago
      That caveat does not match the definition of “effectively” to me.
bsaul 3y ago
i wonder if this isn't going to have the side effect of making some people write more cross platform code in c++.
- pjmlp 3y ago
  The reason why many of us still reach out to C++, is that in many cases the option is only between C or C++, and from both, at least C++ provides some safety knobs.
- dagmx 3y ago
  I think that’s fine as long as there’s no performance penalty. People were doing it anyway. This just eases the friction, and potentially increases performance since many wrappers are really inefficient with regards to data marshalling
- fooker 3y ago
  People are going to keep writing libraries in C++ until there’s a better option.
meisel 3y ago
I’ve been bitten enough by Objective-C++ compiler bugs (Apple’s attempt at mixing Objective-C and C++), as well as bugs in Apple’s code in the Swift ecosystem, not to trust the stability here for at least several years. I also don’t see how this is much better than just creating a C or ObjC wrapper around a C++ library, rather than needing to keep C++‘s complicated language features, and Swift’s interop with it, in my head as I use the library. Were there people clamoring for this? I can’t really see the point.
- pjmlp 3y ago
  History class, Objective-C++ was created by NeXT.
- KerrAvon 3y ago
  Actually compiler bugs or just badly documented interactions between the two models, leading to misunderstandings?
  - eschaton 3y ago
    This is a lot of what folks refer to as compiler bugs when dealing with ObjC++, yeah, usually when they not asking for help and instead just cobbling together their own workarounds.
  - meisel 3y ago
    Address sanitizer violations caused when using C++ containers with ObjC objects
- plorkyeran 3y ago
  I don't think I've ever encountered an obj c++-related compiler bug in close to a decade of working on a ~200k loc Obj-C++ project, and we do pretty aggressively mix obj-c and c++ things
- zapzupnz 3y ago
  It’s more direct is the point. Why add C in between when you can use C++ directly? Like actually, what’s the point of the C in between? It’s only adding yet another thing to maintain when your can just access C++ directly from Swift and vice versa.

84 points by oumua_don17 3y ago

On a related topic of hybrid Swift and C++ tooling - has anyone used Doxygen/Sphinx to generate HML docs for modern Swift, similar to how people do it for pure C++ projects?

dagmx 3y ago
Swift does have docc that does the same https://swift.org/blog/swift-docc/ https://swift.org/blog/swift-docc/ I’ve never had good luck getting documentation working cross language and so I use docc for Swift, doxygen for C++, rustdoc for Rust and Sphinx for Python. Then I just link between them if a project uses more than one language
- ashvardanian 3y ago
  Sure, but how do you style and host those docs? Can you style them identically? We use a combo of Furo + Sphinx + Doxygen for C/C++, Python, JavaScript, Java here: https://unum-cloud.github.io/docs/usearch https://unum-cloud.github.io/docs/usearch For ObjC, Swift, Rust, and other languages we couldn’t make it work for now.
  - dagmx 3y ago
    I gave up on trying to style them exactly the same. I manage my own CSS that brings them closer but they all behave so differently. I wrote my own hosting solution to host multiple doc types and switch between versions. Unfortunately I can’t share it since it’s for work but it wasn’t too hard. Though I wish there was a good off the shelf solution here.
    - ashvardanian 3y ago
      Similar state here. It’s so frustrating. Thx!

Dig1t 3y ago

I have not yet understood who this is for. Are there many developers who have Mac apps written in C++ that want to move their code base to Swift? If so how do they do UI? I thought you needed to at least use Objective-C to use Apple GUI frameworks. Or is there some set of libraries in C++ that are crucial to bring into Swift?

zapzupnz 3y ago
You don’t need to use Objective-C to use the GUI frameworks, haven’t had to for nearly a decade if I’ve been using Swift since then. Now with more and more pure Swift apps, the C++ interop is more direct than having to go through Swift’s existing C interop.

chunkyguy 3y ago

> A C++ class or structure becomes a standalone type in Swift. Its relationship with base C++ classes is not preserved in Swift. C++ `class Fern: public Plant` becomes two different types in Swift `struct Plant` and `struct Fern`, how is this supposed to help anyone? https://www.swift.org/documentation/cxx-interop/#accessing-inherited-members-from-swift https://www.swift.org/documentation/cxx-interop/#accessing-i...

dagmx 3y ago
It still allows you to use them for interop. The only functionality that would be impaired is checking for inheritance with an `as?` type check/conform.
- fooker 3y ago
  No, this blocks a fundamental concept of OOP: Liskov Substitution Principle. The idea is that you should be able to use a derived object anywhere the base one is required.
  - dagmx 3y ago
    It impairs that principle, yes. But it doesn’t block similar patterns that give you similar end results. Swift has very flexible generics programming and type abstraction that still lets you use it with a little extra work. Yes, it won’t be as ergonomic as the ideal, but it’s better than many binding solutions from C++ to compiled languages, while providing most of the usability. Plus the footnote says that they plan to resolve this in future Swift versions.
  - dwaite 3y ago
    It does not import the relationship, but you can still model it via protocols.
mgaunard 3y ago
Interop isn't magic. It can't make the C++ model transparently compatible with that of Swift when the two languages deviate.

kubb 3y ago

C++ interop is impressive, and notoriously hard to get right. This seems like it would be able to cover a lot of APIs. Swift and C# are the well-designed languages I'd rather use at my work instead of Go. It's a real shame both are effectively locked into a specific platform. You can really tell that they had years of attention and careful design by experts in PL poured into them. Go seems like an amateur hobby project in comparison.

wilg 3y ago
I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform. It's no problem to run Swift on Linux or Windows. Of course, Apple's UI libraries aren't cross-platform. And they're putting a bunch of effort into making it better for servers and such. I wish more people realized how usable it is cross-platform, I think this is a misconception that hampers Swift adoption. Swift is definitely my favorite programming language from a language standpoint. I really like the way Swift works. It's safe, concise without being terse, and easy to extend. Sure, some people can argue there's some "bloat", but I think that's inevitable in a language that was designed to immediately be usable within Apple's existing APIs and frameworks. There's going to be complexity with Objective-C interop, C++ interop, etc. But that stuff is necessary for Swift to be usable for big projects. And I think Apple has done quite a good job of evolving Swift to be cleaner, clearer, more ergonomic, etc. I'm very excited that there's a lot of effort behind an open-source, cross-platform type-safe, compiled language that also prioritizes ergonomic high-level programming.
- t0ps0il 3y ago
  > I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform I think the key word in OPs comment is "effectively". The tools for building cross platform Swift exist and work in various levels but they aren't at the point where you would want to choose Swift over existing cross platform tools.
  - wilg 3y ago
    That caveat does not match the definition of “effectively” to me.

bsaul 3y ago

i wonder if this isn't going to have the side effect of making some people write more cross platform code in c++.

pjmlp 3y ago
The reason why many of us still reach out to C++, is that in many cases the option is only between C or C++, and from both, at least C++ provides some safety knobs.
dagmx 3y ago
I think that’s fine as long as there’s no performance penalty. People were doing it anyway. This just eases the friction, and potentially increases performance since many wrappers are really inefficient with regards to data marshalling
fooker 3y ago
People are going to keep writing libraries in C++ until there’s a better option.

meisel 3y ago

I’ve been bitten enough by Objective-C++ compiler bugs (Apple’s attempt at mixing Objective-C and C++), as well as bugs in Apple’s code in the Swift ecosystem, not to trust the stability here for at least several years. I also don’t see how this is much better than just creating a C or ObjC wrapper around a C++ library, rather than needing to keep C++‘s complicated language features, and Swift’s interop with it, in my head as I use the library. Were there people clamoring for this? I can’t really see the point.

pjmlp 3y ago
History class, Objective-C++ was created by NeXT.
KerrAvon 3y ago
Actually compiler bugs or just badly documented interactions between the two models, leading to misunderstandings?
- eschaton 3y ago
  This is a lot of what folks refer to as compiler bugs when dealing with ObjC++, yeah, usually when they not asking for help and instead just cobbling together their own workarounds.
- meisel 3y ago
  Address sanitizer violations caused when using C++ containers with ObjC objects
plorkyeran 3y ago
I don't think I've ever encountered an obj c++-related compiler bug in close to a decade of working on a ~200k loc Obj-C++ project, and we do pretty aggressively mix obj-c and c++ things
zapzupnz 3y ago
It’s more direct is the point. Why add C in between when you can use C++ directly? Like actually, what’s the point of the C in between? It’s only adding yet another thing to maintain when your can just access C++ directly from Swift and vice versa.