January 30, 2017 C++ interop | ||||
---|---|---|---|---|
| ||||
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... |
January 30, 2017 Re: C++ interop | ||||
---|---|---|---|---|
| ||||
Posted in reply to kinke Attachments:
| 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...
>
|
Copyright © 1999-2021 by the D Language Foundation