Conversation
|
So this is only for interfacing with foreign C++ code, not for C++ to interface with D code ? Anyway, a bit of self-promotion: https://forum.dlang.org/post/576C770B.4060408@sociomantic.com ;) |
I agree with @mathias-lang-sociomantic and this restriction should not be added. Compatibility goes both ways. |
|
My ultimate goal is to add interfacing for both ways. I added the restriction only to make it possible to split the development into two steps. I still try to figure out where to change the initialization of a class/struct. @mathias-lang-sociomantic I already work on a PR for the language chance. |
|
I removed the restriction. But without changing the initialization, this is a bit dangerous. @mathias-lang-sociomantic I didn't noticed that @JohanEngelen already created a PR for the spec change! |
You mean dlang/dlang.org#1397 ? That's only for |
redstar
force-pushed
the
cppctor
branch
2 times, most recently
from
a74c461 to
828cd4f
Compare
redstar
force-pushed
the
cppctor
branch
2 times, most recently
from
a500c9a to
ff3cb3c
Compare
Implementing them (wrongly btw, ignoring the msg) leads to an implicit call to the `super` ctor of base class `core.stdcpp.exception.std.exception`, which is only declared in D. Even if the ctor signature was correct (see below), it's mangled differently (see dlang/dmd#5884), so there'd be an unresolved external anyway. So don't implement it, just declare it (also done for Glibc) to defer the linking error. Quality-wise, the 2 `core.stdcpp` modules are at most at an alpha stage for MSVCRT. Other issues I've noted so far using **VS 2015**: * The signature of the `core.stdcpp.exception.std.exception.this()` ctor is wrong. There's no default, i.e., parameter-less one, only `std::exception::exception(const char *_Message = "unknown", int x=1)`. * `std::exception` only contains a pointer, no additional `bool` field. * The signature of `core.stdcpp.typeinfo.std.type_info.name()` is wrong. It doesn't take any arguments. The first 2 aren't crucial, as these C++ exceptions are most likely never constructed on the D side. But the last one will need to be fixed. @rainers: Which VS versions does DMD currently support?
Additionally, it disallows a extern(C++) ctor to have a body. It should be safe to call a C++ ctor from C++ and D as long as the initialization rules from C++ are used. Disallowing an ctor body ensures this.
|
Thanks for your pull request and interest in making D better, @redstar! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + dmd#5884" |
|
This has been part of #8265, I guess we can close this one. |
5 participants
Additionally, it disallows a extern(C++) ctor to have a body.
It should be safe to call a C++ ctor from C++ and D as long as
the initialization rules from C++ are used. Disallowing an ctor
body ensures this.