Link compatibility between C++ and D

Question

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?

---

Update: "D has namespace support in the works" from Walter Bright.

Answer 1

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.