also: catch D exceptions from C++ vs catching C++ exceptions from D; IIRC only one direction is supported
On Mon, Jan 30, 2017 at 11:42 AM, kinke via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > 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... >