www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - State of interfacing with c++

reply Jonas Drewsen <nospam4321 hotmail.com> writes:
For a hack week at work I am thinking about creating a module in 
D that can be used with our existing application which is written 
in C++.

Can anyone shed some light on the current status of interfacing 
with C++? In particular:

1, Can I build my C++ program using visual c++ and then link a D 
module compiled with gdc/ldc/dmd into it using the ms linker?

2, Can I do the same with the OSX tool chain ie. compile main 
program using xcode clang etc.

3, And what about linux?

3, Which features of D or C++ should I expect not to work or 
shouldn't use when interfacing.

Any pointers to reasonably up-to-date info about interfacing with 
c++ is much appreciated as well.

Thanks
Mar 18 2016
next sibling parent reply Johan Engelen <j j.nl> writes:
On Friday, 18 March 2016 at 13:45:18 UTC, Jonas Drewsen wrote:

 For a hack week at work I am thinking about creating a module 
 in D that can be used with our existing application which is 
 written in C++.

 Can anyone shed some light on the current status of interfacing 
 with C++? In particular:

 1, Can I build my C++ program using visual c++ and then link a 
 D module compiled with gdc/ldc/dmd into it using the ms linker?


This is what we do for LDC.
Perhaps the only annoyance is that you have to know what linker 
flags gdc/ldc/dmd use. See 
https://github.com/ldc-developers/ldc/blob/master/CMakeLists.txt#L126-L177
It'd be nice to be able to call `dmd -ldflags` whose output would 
be the standard linker flags.


 3, Which features of D or C++ should I expect not to work or 
 shouldn't use when interfacing.


C++ constructors/destructors are different from their D siblings.
To help with this, you can define creation/destruction helper 
functions that you would call from the other domain, for example 
C++ calling a "Class* createClass(...)" function, defined in D as 
something like
extern(C++) Class createClass(...) {
    return new Class(...);
}
Mar 18 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2016 6:59 AM, Johan Engelen wrote:

 It'd be nice to be able to call `dmd -ldflags` whose output would be the
 standard linker flags.


   dmd -v file.d

will tell you what command is sent to the linker.
Mar 18 2016
parent reply Johan Engelen <j j.nl> writes:
On Friday, 18 March 2016 at 20:47:41 UTC, Walter Bright wrote:

 On 3/18/2016 6:59 AM, Johan Engelen wrote:

 It'd be nice to be able to call `dmd -ldflags` whose output 
 would be the
 standard linker flags.


   dmd -v file.d

 will tell you what command is sent to the linker.


That linker command does not include the path to phobos.
You would have to parse the output, etc...
Mar 19 2016
parent reply Johan Engelen <j j.nl> writes:
On Saturday, 19 March 2016 at 08:10:41 UTC, Johan Engelen wrote:

 On Friday, 18 March 2016 at 20:47:41 UTC, Walter Bright wrote:

 On 3/18/2016 6:59 AM, Johan Engelen wrote:

 It'd be nice to be able to call `dmd -ldflags` whose output 
 would be the
 standard linker flags.


   dmd -v file.d

 will tell you what command is sent to the linker.


 That linker command does not include the path to phobos.
 You would have to parse the output, etc...


Would you accept a PR that adds `dmd -ldflags` ?

For C++/D linking, I used the C++ linker for LDC (master), but 
now I am changing it to using the D compiler with "-L-lstdc++" to 
link. It solves the issue of finding the location of 
phobos/druntime (different for dmd and ldc) and other required 
libs for D code. It also solves a Windows-specific linking 
problem when main() is in C++ code [1].

[1] 
http://forum.dlang.org/post/livbjrlaoliqjtmmwnht forum.dlang.org
Mar 19 2016
parent Johan Engelen <j j.nl> writes:
On Saturday, 19 March 2016 at 10:52:35 UTC, Johan Engelen wrote:

 On Saturday, 19 March 2016 at 08:10:41 UTC, Johan Engelen wrote:

 On Friday, 18 March 2016 at 20:47:41 UTC, Walter Bright wrote:

 On 3/18/2016 6:59 AM, Johan Engelen wrote:

 It'd be nice to be able to call `dmd -ldflags` whose output 
 would be the
 standard linker flags.


   dmd -v file.d

 will tell you what command is sent to the linker.


 That linker command does not include the path to phobos.
 You would have to parse the output, etc...


 Would you accept a PR that adds `dmd -ldflags` ?

 For C++/D linking, I used the C++ linker for LDC (master), but 
 now I am changing it to using the D compiler with "-L-lstdc++" 
 to link. It solves the issue of finding the location of 
 phobos/druntime (different for dmd and ldc) and other required 
 libs for D code. It also solves a Windows-specific linking 
 problem when main() is in C++ code [1].


Unfortunately, this was not true. If your D code does not have 
main(), linking does no work with DMD on Windows: phobos is not 
linked when there is no main(). Note that "phobos" also contains 
druntime and so a D source file with only "void foo() {}" does 
not link, and results in unresolved external symbol _d_assert 
among others.
This is giving me a major headache at the moment while trying to 
change LDC's build.
(on Linux and Mac, it turns out things are easier)
Mar 19 2016
prev sibling next sibling parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Friday, 18 March 2016 at 13:45:18 UTC, Jonas Drewsen wrote:

 Any pointers to reasonably up-to-date info about interfacing 
 with c++ is much appreciated as well.


The language documentation is up to date except for the section 
on exceptions:

http://dlang.org/spec/cpp_interface.html

I'd update the section on exceptions but I'm really tired of 
fighting the dlang.org makefile.

http://forum.dlang.org/post/aupwqmkicdjzwxdkklnt forum.dlang.org
Mar 18 2016
parent tsbockman <thomas.bockman gmail.com> writes:
On Friday, 18 March 2016 at 14:11:46 UTC, Jakob Ovrum wrote:

 I'd update the section on exceptions but I'm really tired of 
 fighting the dlang.org makefile.

 http://forum.dlang.org/post/aupwqmkicdjzwxdkklnt forum.dlang.org


If you'll write an update for the C++ exceptions section as plain 
text, I'll do the DDoc markup, fight with the makefile, and make 
a pull request for you. (I would need you to be available to 
answer content-related questions on the pull request, though.)
Mar 18 2016
prev sibling next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Friday, 18 March 2016 at 13:45:18 UTC, Jonas Drewsen wrote:

 For a hack week at work I am thinking about creating a module 
 in D that can be used with our existing application which is 
 written in C++.

 Can anyone shed some light on the current status of interfacing 
 with C++? In particular:

 1, Can I build my C++ program using visual c++ and then link a 
 D module compiled with gdc/ldc/dmd into it using the ms linker?

 2, Can I do the same with the OSX tool chain ie. compile main 
 program using xcode clang etc.

 3, And what about linux?

 3, Which features of D or C++ should I expect not to work or 
 shouldn't use when interfacing.

 Any pointers to reasonably up-to-date info about interfacing 
 with c++ is much appreciated as well.

 Thanks


If you need only static linking, 1, 2 and 3 should all work fine 
with DMD, if you call into the D module through extern(C) 
functions. If you want use C++ interface it's a little more 
complicated - see http://dlang.org/spec/cpp_interface.html, which 
was updated recently.
The important thing to remember is that the Druntime must be 
initialized (see http://wiki.dlang.org/Runtime_internals and 

info), before you call D functions that use the garbage 
collector. If all your D code is  nogc nothrow, you shouldn't 
need to do any initialization.
AFAIK, GDC doesn't support Windows and is on par with DMD 2.067.
LDC recently got a lot of momentum - the LDC master branch is on 
par with DMD 2.069.2 which means it uses the DMD frontend which 
is written in D, while being a C++ application which uses the C++ 
LLVM interface. It's quite an accomplishment because it would 
make LDC 1.0.0 the largest mixed C++ and D application compiled 
with LDC. There's been also a lot of work on the MSVC front 
lately.
Mar 18 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 18 March 2016 at 14:26:31 UTC, ZombineDev wrote:

 The important thing to remember is that the Druntime must be 
 initialized (see http://wiki.dlang.org/Runtime_internals and 

 info), before you call D functions that use the garbage 
 collector. If all your D code is  nogc nothrow, you shouldn't 
 need to do any initialization.


You mean if you call D functions in C++, you have to use rt_init 
to enable the garbage collector. I don't see that mentioned on 
the Interfacing to C++ page. Probably worth adding.

Other suggestions:
1) Split up the C++ templates section of that page, instead of 
just being big blocks of code.
2) In the memory allocation section, it mentions for ways to 
ensure D garbage is collected properly by C++. Might provide a 
simple example of each technique.
Mar 18 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Friday, 18 March 2016 at 15:29:55 UTC, jmh530 wrote:

 On Friday, 18 March 2016 at 14:26:31 UTC, ZombineDev wrote:

 The important thing to remember is that the Druntime must be 
 initialized (see http://wiki.dlang.org/Runtime_internals and 

 info), before you call D functions that use the garbage 
 collector. If all your D code is  nogc nothrow, you shouldn't 
 need to do any initialization.


 You mean if you call D functions in C++, you have to use 
 rt_init to enable the garbage collector.


I'm sorry, what I said about rt_init() [1] is wrong. It does a 
lot of stuff and it's not just enabling the garbage collector. 
This means you have to be more careful if you decide to not call 
it. Here's what it does:

1. Initializes the global mutex that guards the creation of per 
object monitors, needed for the synchronized (obj) statement.
2. Initializes the first mutex in the critical section linked 
list, needed for the synchronized {} statement.
3. Locates the sections from the binary where the module info & 
module ctor / dtors are located
4. Queries the OS about the clock resolution needed in order for 
MonoTime to be usable.
5. Initializes the internal structures of the GC and reserves 
some initial amount of memory as per the GC config.
6. Adds the static data and bss segments to the GC ranges, so 
they can be scanned.
7. Initializes the callStructDtorsDuringGC flag by reading the GC 
config.
8. Runs shared module ctors
9. Run non-shared module ctors

[1]: 
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L158


 I don't see that mentioned on the Interfacing to C++ page. 
 Probably worth adding.

 Other suggestions:
 1) Split up the C++ templates section of that page, instead of 
 just being big blocks of code.
 2) In the memory allocation section, it mentions for ways to 
 ensure D garbage is collected properly by C++. Might provide a 
 simple example of each technique.


I agree.
Mar 18 2016
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 18 March 2016 at 19:21:08 UTC, ZombineDev wrote:

 I'm sorry, what I said about rt_init() [1] is wrong. It does a 
 lot of stuff and it's not just enabling the garbage collector. 
 This means you have to be more careful if you decide to not 
 call it. Here's what it does:


If it is useful when calling D code from C/C++, then it should be 
mentioned somewhere. And the fact that you've already looked in 
to what it does puts you in a good position to write a summary!
Mar 18 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2016 6:45 AM, Jonas Drewsen wrote:

 [...]


dmd itself is a D main program that calls a lot of C++ code (the optimizer and 
back end) and so interfacing to C++ works on every platform dmd runs on.
Mar 18 2016
parent Jonas Drewsen <nospam4321 hotmail.com> writes:
On Friday, 18 March 2016 at 20:50:59 UTC, Walter Bright wrote:

 On 3/18/2016 6:45 AM, Jonas Drewsen wrote:

 [...]


 dmd itself is a D main program that calls a lot of C++ code 
 (the optimizer and back end) and so interfacing to C++ works on 
 every platform dmd runs on.


My concern was mostly if I could use visual c++ compiled backed 
to link with dmd/ldc/gdc compiled modules or if the c++ part must 
to be compiled a non-vc compiler e.g. dmc, gcc, clang to work.

Because making our existing app compile on e.g. windows using 
something else that visual c++ would definitely increase the work 
load.
Mar 19 2016