4 ms·

Surprised to read that the compiler already supports some C++ types? That’s news to me. It’s not clear to me if that’s already in the shipping compiler or in so

• beached_whale 5y ago
  Right, a C interface without obj-c would be enough to make it much easier
  • jb1991 5y ago
    I already use C interfaces on C++ code to interact directly with Swift without objectiveC. What I’m curious about is if I can actually stop doing even that for many common types? It appears the compiler supposedly already supports that.
    • beached_whale 5y ago
      I didn’t know even that was possible and thought that I had to use objc as it used to be. Nice
      • user-the-name 5y ago
        Objective-C is a superset of C. If there is Objective-C interop, there is by necessity already C interop.
        • BBC-vs-neolibs 5y ago
        • gumby 5y ago
          That is not completely true. There could be object round trip support between objective c and swift objects which would not be available through a C interface. Consider ObjectiveC++ as an example.
          • jb1991 5y ago
            You are talking about something different, I think. Of course, if you need Objective-C features, you don’t get those from C. But if you simply need C features, you don’t need Objective-C just for that. In the context of a C api exposed over C++, objective C is not necessary.
      • conradev 5y ago
        You can also use this to wedge the C preprocessor into Swift for example, I can inject variables into the C preprocessor in my build settings and have a C header that defines constant strings with those variables, which I can then import directly into Swift as a module
    • grayprog 5y ago
      How do you create the C interfaces from C++ code?
      • jb1991 5y ago
        I’m not sure exactly what you’re asking, but it’s just basically writing a C header file as an API, but the implementation is in a source file that is in C++.
        • Tyr42 5y ago
          I mean, you also have to be careful to return pointers and not smart pointers and so on. It can be a bunch of work if you need to write a bunch of freestanding functions to wrap the c++ object methods.
          • jb1991 5y ago
            Well, you won't return smart pointers if your header file is in fact a C API, since smart pointers are C++ only. It's usually as simple as calling data() on a vector or std::string (as well as having a function to return the length or size of the data buffer). And if you wrap your header file in the normal C externs, it shouldn't compile if you do things that are not allowed in C, if I remember. But you are right it can be a lot of work if you have a large surface area. I try to stick to tight, focused APIs, and data is normal C structs which work fine in C++ as well.
        • grayprog 5y ago
          I see, so you're just writing the bridge code yourself. OK, I do the same in Objective-C++, so at least it gives me an object-based interface, as well. But saving this step and having a direct Swift <-> C++ would be helpful.
          • jb1991 5y ago
            Yeah for me it's just about keeping Obj-C out of the project. It's enough to have two languages, I don't want to unnecessarily add a third.
• gavinray 5y ago
  Yes, it has been in the Swift compiler for some time now The original flag was "-experimental-cxx-interop", now it is "-enable-cxx-interop" See here for examples of it in use, including interop with the C++ std library types: https://github.com/plotfi/cxx-interop-test https://github.com/plotfi/cxx-interop-test