Swift C++ interop and Windows

Development Windows
1

Hello all, I'm just starting to look at swift on windows and wanted to start looking at what C++ interop exists, eg how to call into c++ libraries. Does anyone know of any samples of this that I can kick the tires of? I remember that some improved interop capabilities were announced last WWDC or the previous i think in the context of an opensource database that apple uses. thx in advance.

1 Like
2

If you are looking for an example, perhaps GitHub - compnerd/swift-firebase: Swift Interface for Firebase would suffice. That uses C++ interop to build a Firebase access library that is portable to Windows and Android.

2 Likes
3

Here are the instructions, albeit for a specific closed source build system.

4

Why the recommendation for export * in the module map? That isn't exactly best practice, and not the recommended thing for module definitions.

5

Just taken from Swift.org - Mixing Swift and C++ . Quote from there, emphasis mine:

The export * directive is another recommended addition to the module map. It ensures that the types from Clang modules imported into the forestLib module are visible to Swift as well.

I will experiment with removing the export *, thank you for the suggestion.

6

You are right, the export * is not needed. I've updated the recommendations on my website (Update: I reverted the update back to the original version).

There is another problem though (both with and without export *):

If a Swift project that imports C/C++ code via a Clang module is itself a Swift module, it re-exports the Clang module so that the Clang module is importable in projects that import the Swift module.

Swift module Terrain (imports Clang module Forest)
    |
Swift app Earth (imports Swift module Terrain)
can also import Clang module Forest and recognizes all its public code

And here is the problem: If Swift app Earth import Terrain, then it can import Forest as well. If it indeed import Forest and uses some code from it, then the build fails at the link stage with the error "unresolved external symbol".

Can you recommend a way to prevent a Clang module from being re-exported?

7

Update: It is well may be that the export * directive is indeed not needed if a Clang module only uses simple C types. I've briefly experimented with C++, expecting problems with C++ classes. But no, classes seemingly worked. Problems arose when using C++ strings. No problems when using the export * directive.

I've put back the recommendation to include the export * directive in module map files on my website.