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