6 ms·

I think C++ interop is the bigger deal than plain C. You end up needing to launder everything through C because of the lack of standard C++ ABI, plus there's a

I think C++ interop is the bigger deal than plain C. You end up needing to launder everything through C because of the lack of standard C++ ABI, plus there's a bunch of ergonomic awkwardness because C++ and Rust have a bunch of standard-library primitives that serve the same purpose but can't by passed by reference directly (vectors, slices, strings, tuples, etc.), and need to be manually marshaled back and forth if you have a Rust-flavored thing on one side but want to use a C++ library that expects C++-flavored things on the other. I think at least for non-mutable stuff, C++ string_view (approximately rust &str), span (approximately rust slices), and the like should make at least some operations as simple as pointer casts, but having tooling to automate the boilerplate would be nice, and they're also new/not that widely supported (std::span is from C++ 20). And mutable stuff, if you want to be able to write idiomatic/ergonomic code on both sides, seems like a much bigger lift.

eslaught 6y ago
But this is the same story with pretty much every language, right? I remember dealing with some of the C++ interop layers in Common Lisp back about 10 years ago. All around an awful experience, and not really because of either CL or the interop layers themselves. It's just a boatload of complexity and the bigger the C++ library you want to target, the more likely it becomes that you have to deal with essentially all of the language. Compare that to C, where the story is often as good as "import the header and you're done". I'm not sure if there's a good path to a long-term solution, but I've been pushing to get nice C APIs in all the libraries I'm invested in, specifically because of this issue.
- pjmlp 6y ago
  On Windows that solution is COM, which many consider dead, while it actually won the .NET vs COM wars during Longhorn, and was eventually improved with .NET type system (WinRT). So while .NET type type doesn't cover all of C++, it does cover enough not to have clunky C interfaces, and nowadays many Windows APIs only have such COM/UWP interfaces as public API. Microsoft is in the process of adding Rust to their COM/WinRT infrastructure. One of the beauties of COM is that it is interface based component model, so it goes quite well with languages that have interfaces/traits as feature.
  - jstimpfle 6y ago
    Calling simple and idiomatic procedural C interfaces [0] "clunky" and then contrasting them with the abomination that is COM is worthy of disagreement. Maybe the latter has its uses (I've never suffered enough through it to actually use it) but it definitely wins the clunkyness award. And that starts with its ridiculously unsearchable name. [0] I really don't care if in C or a different language, but I'm not aware of relevant programming subcultures where that simplicity of interfacing is such an important pillar to their culture and their success.
    - pjmlp 6y ago
      With first class support (C++/WinRT, VCL, .NET) writing COM components is no different from ordinary C++ classes. Yes, C is clunky and primitive, it was my opinion in 1992 coming from Turbo Pascal 6, and it hasn't changed since.
      - jstimpfle 6y ago
        No different from ordinary C++ classes? (which are themselves more complex than what you need to suffer through with C)? Seriously, here is just one taste of the intricacies of the COM: https://www.codeproject.com/Articles/9190/Understanding-The-COM-Single-Threaded-Apartment-Pa https://www.codeproject.com/Articles/9190/Understanding-The-... This is 90's enterprise OOP technology. There is no good excuse to use this other than technical debt.
        pjmlp 6y ago
        Naturally it is 90's enterprise technology, specially when you dig a 2005 article instead of a 2020 one. There is no good excuse to use outdated articles to attack technology one hates. Here, some 2020 stuff to educate yourself. https://docs.microsoft.com/en-us/windows/uwp/get-started/create-a-basic-windows-10-app-in-cppwinrt https://docs.microsoft.com/en-us/windows/uwp/get-started/cre... When I attack C's clunky and archaic coding, I do so with full knowledge of C17 and how little it has changed with K&R C that I learned in 1992, in API design and OS security.
mcpherrinm 6y ago
There’s a project to help bridge Rust and C++ https://cxx.rs/ https://cxx.rs/
- IshKebab 6y ago
  There is, but it doesn't go as far as something like SWIG for example. You can't point it at a trait and say "make a C++ class for that" or vice versa. SWIG is what people really want.
flohofwoe 6y ago
Even C++ doesn't have proper interoperability with C++ ;) IMHO going through C APIs is fine, because C++ interoperability is much harder and a moving target, just because the language surface is so much bigger than plain C.

eslaught 6y ago

But this is the same story with pretty much every language, right? I remember dealing with some of the C++ interop layers in Common Lisp back about 10 years ago. All around an awful experience, and not really because of either CL or the interop layers themselves. It's just a boatload of complexity and the bigger the C++ library you want to target, the more likely it becomes that you have to deal with essentially all of the language. Compare that to C, where the story is often as good as "import the header and you're done". I'm not sure if there's a good path to a long-term solution, but I've been pushing to get nice C APIs in all the libraries I'm invested in, specifically because of this issue.

pjmlp 6y ago
On Windows that solution is COM, which many consider dead, while it actually won the .NET vs COM wars during Longhorn, and was eventually improved with .NET type system (WinRT). So while .NET type type doesn't cover all of C++, it does cover enough not to have clunky C interfaces, and nowadays many Windows APIs only have such COM/UWP interfaces as public API. Microsoft is in the process of adding Rust to their COM/WinRT infrastructure. One of the beauties of COM is that it is interface based component model, so it goes quite well with languages that have interfaces/traits as feature.
- jstimpfle 6y ago
  Calling simple and idiomatic procedural C interfaces [0] "clunky" and then contrasting them with the abomination that is COM is worthy of disagreement. Maybe the latter has its uses (I've never suffered enough through it to actually use it) but it definitely wins the clunkyness award. And that starts with its ridiculously unsearchable name. [0] I really don't care if in C or a different language, but I'm not aware of relevant programming subcultures where that simplicity of interfacing is such an important pillar to their culture and their success.
  - pjmlp 6y ago
    With first class support (C++/WinRT, VCL, .NET) writing COM components is no different from ordinary C++ classes. Yes, C is clunky and primitive, it was my opinion in 1992 coming from Turbo Pascal 6, and it hasn't changed since.
    - jstimpfle 6y ago
      No different from ordinary C++ classes? (which are themselves more complex than what you need to suffer through with C)? Seriously, here is just one taste of the intricacies of the COM: https://www.codeproject.com/Articles/9190/Understanding-The-COM-Single-Threaded-Apartment-Pa https://www.codeproject.com/Articles/9190/Understanding-The-... This is 90's enterprise OOP technology. There is no good excuse to use this other than technical debt.
      - pjmlp 6y ago
        Naturally it is 90's enterprise technology, specially when you dig a 2005 article instead of a 2020 one. There is no good excuse to use outdated articles to attack technology one hates. Here, some 2020 stuff to educate yourself. https://docs.microsoft.com/en-us/windows/uwp/get-started/create-a-basic-windows-10-app-in-cppwinrt https://docs.microsoft.com/en-us/windows/uwp/get-started/cre... When I attack C's clunky and archaic coding, I do so with full knowledge of C17 and how little it has changed with K&R C that I learned in 1992, in API design and OS security.

mcpherrinm 6y ago

There’s a project to help bridge Rust and C++ https://cxx.rs/ https://cxx.rs/

IshKebab 6y ago
There is, but it doesn't go as far as something like SWIG for example. You can't point it at a trait and say "make a C++ class for that" or vice versa. SWIG is what people really want.

flohofwoe 6y ago

Even C++ doesn't have proper interoperability with C++ ;) IMHO going through C APIs is fine, because C++ interoperability is much harder and a moving target, just because the language surface is so much bigger than plain C.