3 ms·
I agree that the language-level C-FFI is quite good, the `bindgen`/`cbindgen` stuff is ok, but not amazing. I have a fair amount of experience with `cxx`, and
by benreesman 5y ago
I agree that the language-level C-FFI is quite good, the `bindgen`/`cbindgen` stuff is ok, but not amazing.
I have a fair amount of experience with `cxx`, and even with `autocxx`. These tools show a lot of promise but are nowhere in the ballpark of `pybind11` in features, maturity, flexibility, or ease-of-use. It's early days on the Rust <-> C++ journey, which I appreciate might not be a huge concern for a lot of folks, but I depend on a lot of existing C++. My in-house thing ("alloy") is a big mess of `bindgen`/`cbindgen` and pain. It works ok but it's super counterintuitive at best that I budget like 5x the time to hoist something core up into Rust and I do for Python.
I'm excited to see what happens in the space!
- dureuill 5y agoThis is where I stand right now, too. I recently published an overview of Rust <-> C++ interoperability[0], and cxx is the most effective tool available IME, but OTOH even cxx is not there yet (mainly missing bindings for Option and iterators). However the space, especially with autocxx, is evolving rapidly. [0] https://blog.tetrane.com/2022/Rust-Cxx-interop.html https://blog.tetrane.com/2022/Rust-Cxx-interop.html
- virtualritz 5y agoI think you missed `cppmm`[1] which IMHO is one of the most promising projects in that space. https://github.com/vfx-rs/cppmm https://github.com/vfx-rs/cppmm
- dureuill 5y agoInteresting! You're correct that it was not on my radar, don't really know why. Looking at the repository, it looks like the output is a bunch of extern "C" functions, though. Does that mean that one must call eg destructors by hand? How are C++ exceptions handled? Is this sound in the presence of non-relocatable types (eg std::string)? If so, how? Also, this only handles the C++ -> Rust direction, right? Anyway, thank you for letting me know of this project!