3 ms·

Rust has good C interoperability. So from C++ it’d look like a C library. You can either write your own glue code or use something like cbindgen to autogen the

Rust has good C interoperability. So from C++ it’d look like a C library. You can either write your own glue code or use something like cbindgen to autogen the header file.

gmueckl 6y ago
Many interesting SDKs come with C++ APIs that aren't necessarily translatable to C. Choosing Rust for engine development has the potential of severely hamstringing the team. It is the same tough uphill battle for all languages that aren't C++. Even more so now that the smoke is slowly rising from the battlefield of licensed engines and only a few contenders remain standing. And all of them have a massive C++ codebase and litttle incentive to toss that out. If there will be a transition to any other language in that space, it'll take a decade or two.
- virtualritz 6y ago
  There is an effort to automate generating mid-level C bindings for C++ code automagically, to enable easier wrapping in high level Rust APIs, by an unofficial Academy [of Motion Pictures] Software Foundation group. It is called C++-- [1]. At this time we only target the VFX C++ ecosystem but I'd be surprised if people wouldn't use (and extend) this to cover a broader set of C++ libs. Maybe you can give an example of a C++ API that you deem not "translatable to C"? [1] https://github.com/vfx-rs/cppmm https://github.com/vfx-rs/cppmm
  - radarsat1 6y ago
    That's kind of hilarious given the role that C++ to C compiler had in the early development of the language [1]. But sounds useful, thanks for the link. [1] https://en.wikipedia.org/wiki/Cfront https://en.wikipedia.org/wiki/Cfront
    - virtualritz 6y ago
      There is also this, [1], which wasn't on my radar until today: "Corrosion, formerly known as cmake-cargo, is a tool for integrating Rust into an existing CMake project. Corrosion is capable of importing executables, static libraries, and dynamic libraries from a crate." [1] https://github.com/AndrewGaspar/corrosion https://github.com/AndrewGaspar/corrosion
  - gmueckl 6y ago
    For example, OpenVDB uses templates with user provided arguments at the very heart of its tree structure. Similar things happen in PCL and CGAL. They are template-heavy libraries by design. OpenCV on the other hand seems to instantiate all possible variants of cv::Mat for their Python bindings. They don't such a big space of valid and useful template parameters and IIRC the specifics are abstracted away from the algorithms working on them.
- datalus 6y ago
  True, Google is at least trying to make it easier to bind to C++ [0]. It's still pretty experimental, though. 0: https://github.com/google/autocxx https://github.com/google/autocxx
pizza234 6y ago
Interestingly, somebody pointed out in a previous discussion that a potentially significant interoperability hurdle (which is the case for the Qt libraries) is that, if a library makes use of multiple inheritance levels, it translates poorly into any language not supporting inheritance.

Rust has good C interoperability. So from C++ it’d look like a C library. You can either write your own glue code or use something like cbindgen to autogen the header file.

gmueckl 6y ago

Many interesting SDKs come with C++ APIs that aren't necessarily translatable to C. Choosing Rust for engine development has the potential of severely hamstringing the team. It is the same tough uphill battle for all languages that aren't C++. Even more so now that the smoke is slowly rising from the battlefield of licensed engines and only a few contenders remain standing. And all of them have a massive C++ codebase and litttle incentive to toss that out. If there will be a transition to any other language in that space, it'll take a decade or two.

virtualritz 6y ago
There is an effort to automate generating mid-level C bindings for C++ code automagically, to enable easier wrapping in high level Rust APIs, by an unofficial Academy [of Motion Pictures] Software Foundation group. It is called C++-- [1]. At this time we only target the VFX C++ ecosystem but I'd be surprised if people wouldn't use (and extend) this to cover a broader set of C++ libs. Maybe you can give an example of a C++ API that you deem not "translatable to C"? [1] https://github.com/vfx-rs/cppmm https://github.com/vfx-rs/cppmm
- radarsat1 6y ago
  That's kind of hilarious given the role that C++ to C compiler had in the early development of the language [1]. But sounds useful, thanks for the link. [1] https://en.wikipedia.org/wiki/Cfront https://en.wikipedia.org/wiki/Cfront
  - virtualritz 6y ago
    There is also this, [1], which wasn't on my radar until today: "Corrosion, formerly known as cmake-cargo, is a tool for integrating Rust into an existing CMake project. Corrosion is capable of importing executables, static libraries, and dynamic libraries from a crate." [1] https://github.com/AndrewGaspar/corrosion https://github.com/AndrewGaspar/corrosion
- gmueckl 6y ago
  For example, OpenVDB uses templates with user provided arguments at the very heart of its tree structure. Similar things happen in PCL and CGAL. They are template-heavy libraries by design. OpenCV on the other hand seems to instantiate all possible variants of cv::Mat for their Python bindings. They don't such a big space of valid and useful template parameters and IIRC the specifics are abstracted away from the algorithms working on them.
datalus 6y ago
True, Google is at least trying to make it easier to bind to C++ [0]. It's still pretty experimental, though. 0: https://github.com/google/autocxx https://github.com/google/autocxx

pizza234 6y ago

Interestingly, somebody pointed out in a previous discussion that a potentially significant interoperability hurdle (which is the case for the Qt libraries) is that, if a library makes use of multiple inheritance levels, it translates poorly into any language not supporting inheritance.