4 ms·

Back when I was an intern at Mozilla it was a real pain (in my opinion) to call between C++ and Rust. This was before bindgen and cbindgen, and certainly CXX.

Back when I was an intern at Mozilla it was a real pain (in my opinion) to call between C++ and Rust. This was before bindgen and cbindgen, and certainly CXX. Eg if you have a heap allocated thing that is passed between Rust and C++, who frees it? I ended up hacking something together, but it didn't feel right.

xxpor 6y ago
>if you have a heap allocated thing that is passed between Rust and C++, who frees it? Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.
- webkike 6y ago
  There are some things that make this better, such as returning pointer types and not returning raw pointers. Returning raw pointers usually means that another function will delete them. I very rarely see pointers handed back from functions being freed caller side
  - Matthias247 6y ago
    Do you mean references instead of pointers? I'm not familiar of a difference between pointers and raw pointers in C or C++. C++ allows to be more clear: unique_ptrs allow to move ownership, references mean this is definitely not owned, and the remaining questions are around normal pointers. With pure C there is however zero distinction. A pointer can mean ownership is transferred, it is meant to be a reference, it could be a static reference to something in constant memory, etc.
    - webkike 6y ago
      I meant pointers versus types such unique_ptr and shared_ptr
      - Snelius 6y ago
        You will lost his (*_ptr) magic cuz types match is not compatible. Mem must be free on the allocation side, kind of law.
- edflsafoiewq 6y ago
  RAII usually handles all that.
- Paul-ish 6y ago
  Inside both Rust and C++ there are very well developed tools (eg smart pointers) for dealing with memory allocations. These tools were never written to be compatible with each other, so you lose them at the language boundary.
  - xxpor 6y ago
    That makes sense. I do 99% C, so any time I even have to think about C++ it unfortunately turns into C with classes rather than C++, so I'm really not as familiar with the smart pointer options.
stefan_ 6y ago
You need to answer "who frees it" in Rust, too, it just doesn't allow you to screw it up.
rightbyte 6y ago
Surely C++ exceptions and destructors has to be the main issue for interoperation? I've done to many C++ wrappers with C linkage of C++ libs to call from C, that convert exceptions to error codes and free_obj() wrappers to run destructors.
- bialpio 6y ago
  Chromium does not allow using exceptions, so it may not be that important issue to solve.
mkoubaa 6y ago
passing a heap allocated thing from one c++ dll to another doesn't work. it's far better to define a C interface between binaries of any language and reintroduce language specific semantics in a light client library
- ncmncm 6y ago
  You must be talking about Microsoft stuff not applicable here.
  - mkoubaa 6y ago
    Not true. GCC broke compatibility with the memory layout of are string at c++11 and passing those between DLLs with versions of GCC on either side of that change will crash. The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium
    - ncmncm 6y ago
      Now you are changing the subject. Allocation, which was the subject, happens the same way on either side of gcc's C++11 boundary. The C++11 break was required by the ISO Standard issued in 2011. The Gcc and libstdc++ maintainers are extremely careful to maintain ABI compatibility between widely-separated releases, where permitted by the Standard. You can happily call between code compiled with gcc-6 and gcc-10, release or debug, optimized or not. It is possible to deliberately vary ABI with compiler options, but nobody uses those for shared libraries they distribute, for obvious reasons, with the unique exception of choosing pre-C++11 vs post-C++11 ABI.
      - mkoubaa 6y ago
        I guess you're right. I still am wary about depending on this given the current conversation about ABI evolution with C++. And given that lots of languages can interop with C I think building C interfaces between binaries buys options

xxpor 6y ago

>if you have a heap allocated thing that is passed between Rust and C++, who frees it? Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.

webkike 6y ago
There are some things that make this better, such as returning pointer types and not returning raw pointers. Returning raw pointers usually means that another function will delete them. I very rarely see pointers handed back from functions being freed caller side
- Matthias247 6y ago
  Do you mean references instead of pointers? I'm not familiar of a difference between pointers and raw pointers in C or C++. C++ allows to be more clear: unique_ptrs allow to move ownership, references mean this is definitely not owned, and the remaining questions are around normal pointers. With pure C there is however zero distinction. A pointer can mean ownership is transferred, it is meant to be a reference, it could be a static reference to something in constant memory, etc.
  - webkike 6y ago
    I meant pointers versus types such unique_ptr and shared_ptr
    - Snelius 6y ago
      You will lost his (*_ptr) magic cuz types match is not compatible. Mem must be free on the allocation side, kind of law.
edflsafoiewq 6y ago
RAII usually handles all that.
Paul-ish 6y ago
Inside both Rust and C++ there are very well developed tools (eg smart pointers) for dealing with memory allocations. These tools were never written to be compatible with each other, so you lose them at the language boundary.
- xxpor 6y ago
  That makes sense. I do 99% C, so any time I even have to think about C++ it unfortunately turns into C with classes rather than C++, so I'm really not as familiar with the smart pointer options.

stefan_ 6y ago

You need to answer "who frees it" in Rust, too, it just doesn't allow you to screw it up.

rightbyte 6y ago

Surely C++ exceptions and destructors has to be the main issue for interoperation? I've done to many C++ wrappers with C linkage of C++ libs to call from C, that convert exceptions to error codes and free_obj() wrappers to run destructors.

bialpio 6y ago
Chromium does not allow using exceptions, so it may not be that important issue to solve.

mkoubaa 6y ago

passing a heap allocated thing from one c++ dll to another doesn't work. it's far better to define a C interface between binaries of any language and reintroduce language specific semantics in a light client library

ncmncm 6y ago
You must be talking about Microsoft stuff not applicable here.
- mkoubaa 6y ago
  Not true. GCC broke compatibility with the memory layout of are string at c++11 and passing those between DLLs with versions of GCC on either side of that change will crash. The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium
  - ncmncm 6y ago
    Now you are changing the subject. Allocation, which was the subject, happens the same way on either side of gcc's C++11 boundary. The C++11 break was required by the ISO Standard issued in 2011. The Gcc and libstdc++ maintainers are extremely careful to maintain ABI compatibility between widely-separated releases, where permitted by the Standard. You can happily call between code compiled with gcc-6 and gcc-10, release or debug, optimized or not. It is possible to deliberately vary ABI with compiler options, but nobody uses those for shared libraries they distribute, for obvious reasons, with the unique exception of choosing pre-C++11 vs post-C++11 ABI.
    - mkoubaa 6y ago
      I guess you're right. I still am wary about depending on this given the current conversation about ABI evolution with C++. And given that lots of languages can interop with C I think building C interfaces between binaries buys options