Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

D still requires you to write bindings, see 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-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.




> 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.


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/do...


AIUI, you don't need to use D with a garbage collector. It can be disabled.


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


You don't need non-GC stdlib for C++ interop, though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: