tags:

views:

558

answers:

3

D easily interfaces with C.

D just as easily interfaces with C++, but (and it's a big but) the C++ needs to be extremely trivial. The code cannot use:

  • namespaces
  • templates
  • multiple inheritance
  • mix virtual with non-virtual methods
  • more?

I completely understand the inheritance restriction. The rest however, feel like artificial limitations. Now I don't want to be able to use std::vector<T> directly, but I would really like to be able to link with std::vector<int> as an externed template.

The C++ interfacing page has this particularly depressing comment.

D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D.

This means that the C++ STL, and C++ Boost, likely will never be accessible from D.

Admittedly I'll probably never need std::vector while coding in D, but I'd love to use QT or boost.

So what's the deal. Why is it so hard to express non-trivial C++ classes in D? Would it not be worth it to add some special annotations or something to express at least namespaces?

+14  A: 

As Hans Passant mentions in a comment, the level of interoperability you want between D and C++ isn't even supported among different C++ compilers. There is a C++ ABI (Application Binary Interface) standard that seems to have some support, but I'm not sure exactly how extensive (Intel, GCC and ARM compilers seem to follow the ABIs). I haven't had a need to use it, and I'm not sure whether or not Microsoft adheres to it for their x86 or x64 compilers (I imagine it might for ia64, since that's where the ABI standard started).

See "Interoperability & C++ Compilers" by Joe Goodman for some details on the C++ ABI.

Maybe Walter Bright can be convinced to support D interoperability with C++ libraries/objects that follow the ABI standard (though I'm not sure where he might prioritize it).

Michael Burr
+16  A: 

FWIW Qt has an actively developed binding for D: http://www.dsource.org/projects/qtd

I think many components in boost are too highly tied to C++ to be portable meaningfully to other languages.

Using e.g. std::vector is possible if you spend the time on writing regular (e.g. namespace-level) functions that forward to the appropriate member functions. Tedious, but affordable (for higher-level components; probably not for std::vector).

Also, I very recently checked in the standard library a sealed array and sealed binary heap implementation that use reference counting, malloc/free, and deterministic destruction instead of garbage collection (see http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/container.d). Other containers will follow. These containers use three specific techniques (described in my upcoming article "Sealed Containers") to achieve deterministic destruction without compromising program safety.

Hopefully sealed containers will obviate any need to link with STL containers, even for tight applications that can't afford garbage collection.

Andrei
With known just a little about STL and without know a lot about Boost, I'd assert that there will be almost nothing in either than can't be done as well or better in D. That said, being able to use them would allow better interaction with higher level C++ code.
BCS
The boost library that I wanted in particular was Boost.Asio. I don't know of a comparable cross platform networking library. I'm sure I could find others. Also it's not that a similar library couldn't be written in D, it's that it's already been written, tested, and been used lots of different projects.
caspin
+1  A: 

Just for fun I've been interfacing to some C++ code.

That probably won't answer for your question, but I think you (and some folks among the D community) might be interested in some notes I've made then. Here it goes: TechNotes.

GiM