4 ms·

AFAIK some languages can use C++ fairly easily, including D and Rust

by jchook 6y ago

kccqzy 6y ago
These languages can use C fairly easily. To use C++, you must wrap the C++ interface in `extern "C"` interfaces. It's very hard to use the full spectrum of C++ features. Consider that you're writing a custom struct/data type called MyStruct in your language. Now, can you use std::vector<MyStruct>? This requires your other language to read the entire vector header and instantiate a new type based on both your definition of your custom type and the vector template. The vector instantiation will ask questions like whether or not your type is copy constructible and move constructible, and if so, use these implementations. Designing this into your other language requires a lot of compromises. And that's just templates. ADL poses an even bigger difficulty. Again when you write your custom type in your language and define a swap function for it, will C++ standard algorithms that need swapping find your implementation via ADL? Recall that swapping is invoked via having `using std::swap;` and then invoking the bare function `swap` which triggers ADL. Again, designing this into your other language requires a lot of compromises. The only language that I know of that comes close to having full interoperability with C++ is Objective-C, and it does so by creating a new Frankenstein language called Objective-C++. It has two different kinds of classes, two different exception mechanisms, etc.
- pjmlp 6y ago
  Wrong, D has support for C++ FFI. https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
  - kccqzy 6y ago
    It supports neither templates nor ADL, the two of my examples. In fact the doc says, > Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. It then goes on to describe the pragmatic approach that doesn't allow full compatibility: > D takes a pragmatic approach that assumes a couple modest accommodations can solve a significant chunk of the problem: > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Can you see how limited this subset of interoperable API is?
    - pjmlp 6y ago
      I didn't state it supports 100% compatibility, and it is still better than being stuck with an OS ABI from the 70s, that is only meaningful when the underlying OS is written in C anyway.
    - gpderetta 6y ago
      > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Basically COM? Which is not surprising as it was designed as an OO native FFI.
      - pjmlp 6y ago
        And UWP improves on it, giving more C++ features across the ABI, basically what .NET v1.0 should have been all along.

AFAIK some languages can use C++ fairly easily, including D and Rust

by jchook 6y ago

AFAIK some languages can use C++ fairly easily, including D and Rust

These languages can use C fairly easily. To use C++, you must wrap the C++ interface in `extern "C"` interfaces. It's very hard to use the full spectrum of C++ features. Consider that you're writing a custom struct/data type called MyStruct in your language. Now, can you use std::vector<MyStruct>? This requires your other language to read the entire vector header and instantiate a new type based on both your definition of your custom type and the vector template. The vector instantiation will ask questions like whether or not your type is copy constructible and move constructible, and if so, use these implementations. Designing this into your other language requires a lot of compromises. And that's just templates. ADL poses an even bigger difficulty. Again when you write your custom type in your language and define a swap function for it, will C++ standard algorithms that need swapping find your implementation via ADL? Recall that swapping is invoked via having `using std::swap;` and then invoking the bare function `swap` which triggers ADL. Again, designing this into your other language requires a lot of compromises. The only language that I know of that comes close to having full interoperability with C++ is Objective-C, and it does so by creating a new Frankenstein language called Objective-C++. It has two different kinds of classes, two different exception mechanisms, etc.

pjmlp 6y ago
Wrong, D has support for C++ FFI. https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
- kccqzy 6y ago
  It supports neither templates nor ADL, the two of my examples. In fact the doc says, > Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. It then goes on to describe the pragmatic approach that doesn't allow full compatibility: > D takes a pragmatic approach that assumes a couple modest accommodations can solve a significant chunk of the problem: > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Can you see how limited this subset of interoperable API is?
  - pjmlp 6y ago
    I didn't state it supports 100% compatibility, and it is still better than being stuck with an OS ABI from the 70s, that is only meaningful when the underlying OS is written in C anyway.
  - gpderetta 6y ago
    > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Basically COM? Which is not surprising as it was designed as an OO native FFI.
    - pjmlp 6y ago
      And UWP improves on it, giving more C++ features across the ABI, basically what .NET v1.0 should have been all along.