I was wondering whether C++ interop is already considered sufficiently working enough, as I don't see any plans for improving it in the H1 2017 vision, except for the `C++ stdlib interface` bullet point.

IMO, the main obstacles for mixed D/C++ RAII-style code are:

1) Constructors don't work across the C++/D language barrier, as they are mangled differently and slightly differ in semantics (D ctors assume the instance is pre-initialized with T.init) => currently need to implement them on both sides. Additionally, D structs cannot have a non-disabled parameter-less constructor.
2) Destructors need to be implemented on both sides as well.
3) Copy/move constructors/assignment operators too.

I think D could do a lot better. Constructors for example:

// D
extern(C++) struct T {
  this(bool a); // declares C++ ctor T::T(bool)

  extern(D) this(int a)
  {
    // Generates D ctor T::__ctor(int) and C++ ctor T::T(int).
// The C++ ctor is implemented as `{ this = T.init; this.__ctor(a); }`
    // to initialize the memory allocated by C++ callers.
// D clients call the D __ctor directly to avoid double-initialization;
    // that's what the extern(D) makes explicit.
  }
}

// C++
struct T {
  T(bool a) {
    // Callable from D; instance will be initialized twice then.
  }

T(int a); // declares the C++ ctor wrapper emitted by the D compiler
};

Similarly, the D compiler could generate explicit C++ copy and move constructors automatically if the extern(C++) struct has an extern(D) postblit ctor, so that C++ clients only need to declare them. `extern(C++) this(this);` postblit ctor declarations could be used to make D clients call copy/move ctors implemented in C++ etc...
  • C++ interop kinke via Digitalmars-d

Reply via email to