C++ interop
kinke via Digitalmars-d
digitalmars-d at puremagic.com
Mon Jan 30 11:42:24 PST 2017
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...
More information about the Digitalmars-d
mailing list