I work for a very large Medical company building a large K/N app for them. My company is reviewing if they can use K/N elsewhere but the biggest stumble blocks is we have a lot of C++ code (most C++ 89 some C++ 11) in libraries we looking to reuse. I have identity the following solutions
a) Write our own C wrapper manually from our C++ code and call them from K/N using the C cinterop tool
b) Extend K/N to scan our C++ headers files and somehow auto-generates our C header files wrappers using extern "C" so we can reuse the C interop solution.
c) Get SWIG to do the C generations for me (SWIG support 22 languages but C headers from C++ is not one of them)
d) Use CLang libtool to generate the C binding. Its requires C++ and is a last resort and is a compiler based solution.
Since choice c) and d) are dubious solutions, and a) is completely manual I like to try option b) by joining the project as a contributor and tackle this problem. I understand that K/N interop with C++ is not planned but I like to give it a go with a solution similar to how the Objective-C wrapper was done. I fully understand that dealing with templates and exceptions will be difficult. Express feedback please.
This looks very interesting, and generally we believe that Kotlin interop with some subset of C++ is feasible. So your contributions are very welcome, however we would suggest to coordinate with us how languages are being mapped around aspects different in C++ and Kotlin. To name a few:
We are also interested in this project. We are researching whether it would be possible to add a Kotlin / Native wrapper around our OMNeT++ Discrete Event Simulator API, which is fairly conservative C++11 code.
Meanwhile I am trying to wrap some Skia libraries into K/N.
I am little torn on where to begin. I believe the best approach is to
enhance the Kotlin Native C Interopt tool functionality as I trying to
reuse its C bindings when possible. By passing extra flags it will scan C++
header files and generate the wrapper using the C Wrapper functionality. I
believe this is better than providing yet another tool as most developers
will think if the tool handle C headers whey not C++17 header files. Unless
JetBrains disagrees I will proceed down this path with Interopt patches
unless they think build a new tool is needed. I am planning on using a
bridge design pattern where every class reference is stored in a global
structure in the C wrapper as JNI does it. My C wrapper will of course have
to keep track of C++ references and exceptions thrown in C++ and passed
back to my wrapper from the C++ library I trying to wrap.
Any thoughts?
On Fri, Jul 5, 2019 at 6:32 AM Nickolay notifications@github.com wrote:
Meanwhile I am trying to wrap some Skia libraries into K/N.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/JetBrains/kotlin-native/issues/2835?email_source=notifications&email_token=AAIH65IIAH7254HPRGXH66LP55EOVA5CNFSM4HCSADPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJRAGQ#issuecomment-508760090,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIH65LMSPHICPQLTNAYTNDP55EOVANCNFSM4HCSADPA
.
Yes, makes sense. And language = C++ shall control C++ bindings creation, like it's done for C/Objective-C already. See https://github.com/JetBrains/kotlin-native/blob/8a816adcbe77096026abeb5051113a8d0062acaa/Interop/StubGenerator/src/main/kotlin/org/jetbrains/kotlin/native/interop/gen/jvm/main.kt#L85
Do you guys have a branch, we also reach to the topic, maybe can contribute?
Just publishing my first commit
https://github.com/JetBrains/kotlin-native/pull/3487
I need reviewers
@olonho are there any efforts from Jetbrains/Kotlin organization to make interop work with C++ libraries? As I don't understand the technical consequences, how much effort would it be? Would help help Kotlin become more popular So much C++ out there...
The discussed initiative seems pretty much abandoned.
are there any efforts from Jetbrains/Kotlin organization to make interop work with C++ libraries?
Not at the moment.
As I don't understand the technical consequences, how much effort would it be?
It significantly depends on the supported subset of C++ (features).
Most helpful comment
This looks very interesting, and generally we believe that Kotlin interop with some subset of C++ is feasible. So your contributions are very welcome, however we would suggest to coordinate with us how languages are being mapped around aspects different in C++ and Kotlin. To name a few: