News for hackers. Stuff that matters.
Re:Swift and C++ interoperability workgroup announcement by jb1991 on Tuesday February 01, 2022 @08:54AM (#30162373)
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.
Re:Swift and C++ interoperability workgroup announcement by beached_whale on Tuesday February 01, 2022 @09:02AM (#30162486)
I didn’t know even that was possible and thought that I had to use objc as it used to be. Nice
Re:Swift and C++ interoperability workgroup announcement by user-the-name on Tuesday February 01, 2022 @09:11AM (#30162595)
Objective-C is a superset of C. If there is Objective-C interop, there is by necessity already C interop.
Re:Swift and C++ interoperability workgroup announcement by gumby on Tuesday February 01, 2022 @10:04AM (#30163378)
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.
Re:Swift and C++ interoperability workgroup announcement by jb1991 on Tuesday February 01, 2022 @10:48AM (#30164064)
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.
Re:Swift and C++ interoperability workgroup announcement by conradev on Tuesday February 01, 2022 @10:34AM (#30163870)
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

Re:Swift and C++ interoperability workgroup announcement by grayprog on Tuesday February 01, 2022 @10:20AM (#30163641)
How do you create the C interfaces from C++ code?
Re:Swift and C++ interoperability workgroup announcement by jb1991 on Tuesday February 01, 2022 @10:45AM (#30164030)
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++.
Re:Swift and C++ interoperability workgroup announcement by grayprog on Tuesday February 01, 2022 @11:27AM (#30164827)
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.
Re:Swift and C++ interoperability workgroup announcement by jb1991 on Tuesday February 01, 2022 @11:34AM (#30164984)
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.
Re:Swift and C++ interoperability workgroup announcement by quux on Wednesday February 02, 2022 @09:33AM (#30178064)
Don't you already have 3 languages to think about? Swift, C and C++?
Re:Swift and C++ interoperability workgroup announcement by jb1991 on Wednesday February 02, 2022 @11:04AM (#30179411)
The C API is usually syntactically valid C++, so I don’t think of it that way. It’s just an API. Implementation is still in just two languages.
Re:Swift and C++ interoperability workgroup announcement by Tyr42 on Tuesday February 01, 2022 @11:08AM (#30164403)
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.
Re:Swift and C++ interoperability workgroup announcement by jb1991 on Tuesday February 01, 2022 @11:23AM (#30164739)
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.