• kinke (41/41) Jan 30 2017 I was wondering whether C++ interop is already considered
• Timothee Cour via Digitalmars-d (4/40) Jan 30 2017 also: catch D exceptions from C++ vs catching C++ exceptions from D; IIR...

kinke <noone nowhere.com> writes:

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...

Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:

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...