from Hacker News

Why Foreign Function Interfaces are not an easy answer (2012)

by wheresvic4 on 1/16/22, 8:02 AM with 12 comments

  • by coldtea on 1/16/22, 7:15 PM

    >A C interface (a function) is exposed only through its name, and no other data; the name does not encode either the number of the type of parameters, which means that you can’t reflectively load the ABI based off the symbols in a shared object.

    What prevents GCC and Clang (and co from Intel/MS) saving a sidecar file next to a program/.so with all the functions and their argument types, struct structures, etc. in some agreed upon format for easy parsing / use? Could even be emitted based on some annotation/pragma like #export before the function declaration.

    Is it just that nobody really cares to coordinate such a solution?

  • by pjmlp on 1/16/22, 8:20 AM

    On this note, there is also a talk at last's year CppCon.

    "Making Libraries Consumable for Non-C++ Developers"

    https://www.youtube.com/watch?v=4r09pv9v1w0

  • by wolframhempel on 1/16/22, 1:09 PM

    For deepstream.io we've gotten quite far with a mix of node and c++ with both languages operating on the same buffer of typed arrays.

    Our argument for this weird symbiosis was that we wanted the popularity of the NodeJS ecosystem at the time with the performance of C++ - and we achieved this to an at least satisfactory degree.

    When it came to building binaries based on the mixed codebases, especially for windows, things were a lot more challenging.

  • by henrydark on 1/16/22, 1:28 PM

    This is independent of the valid points of the article, but I have found much success in moving to only using types and constructs that adhere to the apache arrow specification.

    To tie it back to the piece, it would be pretty easy to generate code that outputs function definitions from an apache arrow scheme in both C and a target interpreted language such as python (e.g. ctypes bindings).

  • by sharikous on 1/16/22, 11:39 AM

    Should be (2012)