However just like you can export Rust code with a C ABI by writing the required boilerplate, the same can be done in C++. Since C++ has native support for C, this is very simple. As an example a class that looks like this (lot of stuff omitted for clarity):
class Foo {
public:
Foo();
~Foo();
void poke(int x);
};
becomes this:
struct CFoo;
struct CFoo* foo_create();
void foo_destroy(struct CFoo *f);
void foo_poke(struct CFoo *f, int x, char **error);
The implementation for each of these just casts CFoo* into Foo* and then calls the corresponding method. The last function handles errors roughly in the same way as GLib's GError. In case of an error the error message is put in the error parameter and it is the responsibility of the caller to check it. For simplicity this is a string, but it could be an error object as well.
This is straightforward but the big problem comes in reporting errors. Writing code to convert exceptions to error messages for each and every function is tedious and error-prone. Fortunately there is a simple solution called an hourglass shaped interface using a Lippincott function. With it the implementation of foo_poke looks like this:
void convert_exception(char **error) noexcept {
char *msg;
try {
throw; // The magic happens here
} catch(const std::exception &e) {
msg = strdup(e.what());
} catch(...) {
msg = strdup("An unknown error happened.");
}
*error = msg;
}
void foo_poke(struct CFoo* f, int x, char **error) {
try {
reinterpret_cast<Foo*>(f)->poke(x);
} catch(...) {
convert_exception(error);
}
}
Here we have moved all error handling away from the wrapper into a standalone helper function. All interface functions have now been reduced into just calling to the real function and, in case of errors, calling the converter. The reason this works is that C++ stores the exception that is currently in flight and allows it to be rethrown. You can think of it as an invisible argument to the converter function.
This simple construct allows us to expose C++ libraries with a plain C ABI with all the stability guarantees and interoperability goodness that entails. A full sample project can be found here. It also contains a C++ "unwrapper" on top of the plain C API that makes exceptions travel transparently over the interface (that is, using the exact same ABI).
I see your point about scripting languages that only can call native code via C ABI. Well, but that's rather a limitation of these scripting languages. C++ ABIs are documented and rather stable. Sufficiently stable to let major C++ libraries give rather broad compatibility promises. For instance Qt promises[1] that programs linked against Qt 5.0, which was released four years ago, still should work with the latest and greatest binaries.
ReplyDelete[1] https://wiki.qt.io/Qt-Version-Compatibility
Sure you can make stable ABIs with C++ (ignoring the stdlibc++ breakages that happen roughly once a year) but if you want to create a shared library that can be used by everybody (similar to zlib, libpng, or glib), it must have a plain C API + ABI. This is unfortunate but also a fact of life.
ReplyDelete