3 ms·

D still requires you to write bindings, see https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html Also D objects have a different

D still requires you to write bindings, see https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html Also D objects have a different lifetimes & requirements, which complicates things ( see https://dlang.org/spec/cpp_interface.html#lifetime-management https://dlang.org/spec/cpp_interface.html#lifetime-managemen... ) Carbon appears to be auto-generating bi-directional bindings, and since it has the same memory model has no such awkward interactions between non-GC'd and GC'd worlds like D does.

zozbot234 4y ago
> Also D objects have a different lifetimes & requirements, which complicates things Does Carbon actually solve these issues, though? It would be great if it did, but they don't list complete interop w/ C++ as an actual goal of theirs, only enough to make it practically viable for development.
- kllrnohj 4y ago
  Carbon's memory model is compatible with C++'s[1], so where would you foresee complications? D could have been so much better here if it just hadn't chosen to be a GC'd language. That single choice pretty much kills any easy interop. 1: "For example, C++ and Carbon will use the same memory model." https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#bidirectional-interoperability-with-c-and-c https://github.com/carbon-language/carbon-lang/tree/trunk/do...
  - zozbot234 4y ago
    AIUI, you don't need to use D with a garbage collector. It can be disabled.
    - dymk 4y ago
      The D standard library is heavily tied to the GC. If you want to avoid the GC, you'd have to give up the standard library, and if you do that, you have to give up most of the D ecosystem. As far as I can tell, there hasn't been progress in untying the stdlib from the GC - https://github.com/dlang/projects/issues/56 https://github.com/dlang/projects/issues/56
      - deleted 4y ago
        [deleted]
      - int_19h 4y ago
        You don't need non-GC stdlib for C++ interop, though.
KerrAvon 4y ago
This is true, although there is this: https://dlang.org/blog/2019/04/08/project-highlight-dpp/ https://dlang.org/blog/2019/04/08/project-highlight-dpp/

zozbot234 4y ago

> Also D objects have a different lifetimes & requirements, which complicates things Does Carbon actually solve these issues, though? It would be great if it did, but they don't list complete interop w/ C++ as an actual goal of theirs, only enough to make it practically viable for development.

kllrnohj 4y ago
Carbon's memory model is compatible with C++'s[1], so where would you foresee complications? D could have been so much better here if it just hadn't chosen to be a GC'd language. That single choice pretty much kills any easy interop. 1: "For example, C++ and Carbon will use the same memory model." https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#bidirectional-interoperability-with-c-and-c https://github.com/carbon-language/carbon-lang/tree/trunk/do...
- zozbot234 4y ago
  AIUI, you don't need to use D with a garbage collector. It can be disabled.
  - dymk 4y ago
    The D standard library is heavily tied to the GC. If you want to avoid the GC, you'd have to give up the standard library, and if you do that, you have to give up most of the D ecosystem. As far as I can tell, there hasn't been progress in untying the stdlib from the GC - https://github.com/dlang/projects/issues/56 https://github.com/dlang/projects/issues/56
    - deleted 4y ago
      [deleted]
    - int_19h 4y ago
      You don't need non-GC stdlib for C++ interop, though.

KerrAvon 4y ago

This is true, although there is this: https://dlang.org/blog/2019/04/08/project-highlight-dpp/ https://dlang.org/blog/2019/04/08/project-highlight-dpp/