Hacker News Reader

Comment by beached_whale | Hacker News Reader

Right, a C interface without obj-c would be enough to make it much easier

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.

I didn’t know even that was possible and thought that I had to use objc as it used to be. Nice

Objective-C is a superset of C. If there is Objective-C interop, there is by necessity already C interop.

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.

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.

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

How do you create the C interfaces from C++ code?

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++.

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.

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.

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.

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.

Don't you already have 3 languages to think about? Swift, C and C++?

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.

Reply on news.ycombinator.com