A half year ago I discovered a presentation with code about hourglass interfaces. The principle of the hourglass interface is to add a C-layer between library and application, such that you don’t have to deal with C++ ABI differences between compilers, but can benefit from the fact that anything supports C foreign function interfaces, including C++ itself. A binary library can then swapped out and updated without needing to update the application, which is especially convenient if the library is your product that is used by third parties (who distribute their app plus your lib as a binary). Since anything can call into the C lib, you can now use different languages if you want to! I guess it’s no longer an hourglass interface, but a good old C binding, but they come down to the exact same thing.

Well, so far I was all talk, but now I have some meat to serve! My postdoc_tools repo has two interfaces to C components, one is supplied with it. One thing that became clear during writing these binding is fully understanding that the CFFI is a function interface. You can extern function, nothing else. No classes, no datatypes, nope. (Unless I missed something.) Basic types present in C89 are available, such as ints and floats, but not even bools. So for libgpumcd I wrote a bunch of structs, in the C wrapper and then in the Python binding, and these of course must match because otherwise the function will not recognize it.

I went from zero to writing GPUMCD simulations in Python within the week, so for me this week was good. I feel like I levelled up and think knowing how to do this will prove useful in the time to come. A Pascal wrapper is in the pipeline.