www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Calling D from C++

reply Loopback <elliott.darfink gmail.com> writes:
Hello!

As of my understanding you can write usable c libraries in D by using
extern(C). The problem is that I haven't found any other threads asking
the same question about C++ (since extern for c++ exists as well). So
I have two questions, is it possible to write a dll in D usable in c++
code, and if the answer is yes, are there any restrictions?

Am I forced to use explicit memory handling, or can this be handled by
the garbage collection internally by the dll etc?
Jul 17 2011
parent reply Loopback <elliott.darfink gmail.com> writes:
On 2011-07-17 21:45, Loopback wrote:
 Hello!

 As of my understanding you can write usable c libraries in D by using
 extern(C). The problem is that I haven't found any other threads asking
 the same question about C++ (since extern for c++ exists as well). So
 I have two questions, is it possible to write a dll in D usable in c++
 code, and if the answer is yes, are there any restrictions?

 Am I forced to use explicit memory handling, or can this be handled by
 the garbage collection internally by the dll etc?

Sorry for mentioning this a bit late but noticed this now; http://www.digitalmars.com/d/2.0/cpp_interface.html Although if someone has own experiences or something interesting to say about the matter, please do.
Jul 17 2011
next sibling parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/17/2011 3:53 PM, Loopback wrote:
 On 2011-07-17 21:45, Loopback wrote:
 Hello!

 As of my understanding you can write usable c libraries in D by using
 extern(C). The problem is that I haven't found any other threads asking
 the same question about C++ (since extern for c++ exists as well). So
 I have two questions, is it possible to write a dll in D usable in c++
 code, and if the answer is yes, are there any restrictions?

 Am I forced to use explicit memory handling, or can this be handled by
 the garbage collection internally by the dll etc?

Sorry for mentioning this a bit late but noticed this now; http://www.digitalmars.com/d/2.0/cpp_interface.html Although if someone has own experiences or something interesting to say about the matter, please do.

I think you're going to be better off defining your D routines as extern(C) and then defining the C++ headers as __cdecl (for Windows of course). C++ can, of course, link against libraries using cdecl. If you write your D DLL with the normal DllEntry (this came from VisualD): import std.c.windows.windows; import core.dll_helper; __gshared HINSTANCE g_hInst; extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved) { switch (ulReason) { case DLL_PROCESS_ATTACH: g_hInst = hInstance; dll_process_attach( hInstance, true ); break; case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true ); break; case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break; case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break; } return true; } Then as soon as your DLL is loaded the D runtime will start. Any memory allocated in the D DLL will be garbage collected as you'd imagine. Obviously, it's not going to free any memory allocated in your C++ code ;)
Jul 17 2011
parent reply Loopback <elliott.darfink gmail.com> writes:
On 2011-07-17 22:51, Johann MacDonagh wrote:
 On 7/17/2011 3:53 PM, Loopback wrote:
 On 2011-07-17 21:45, Loopback wrote:
 Hello!

 As of my understanding you can write usable c libraries in D by using
 extern(C). The problem is that I haven't found any other threads asking
 the same question about C++ (since extern for c++ exists as well). So
 I have two questions, is it possible to write a dll in D usable in c++
 code, and if the answer is yes, are there any restrictions?

 Am I forced to use explicit memory handling, or can this be handled by
 the garbage collection internally by the dll etc?

Sorry for mentioning this a bit late but noticed this now; http://www.digitalmars.com/d/2.0/cpp_interface.html Although if someone has own experiences or something interesting to say about the matter, please do.

I think you're going to be better off defining your D routines as extern(C) and then defining the C++ headers as __cdecl (for Windows of course). C++ can, of course, link against libraries using cdecl. If you write your D DLL with the normal DllEntry (this came from VisualD): import std.c.windows.windows; import core.dll_helper; __gshared HINSTANCE g_hInst; extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved) { switch (ulReason) { case DLL_PROCESS_ATTACH: g_hInst = hInstance; dll_process_attach( hInstance, true ); break; case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true ); break; case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break; case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break; } return true; } Then as soon as your DLL is loaded the D runtime will start. Any memory allocated in the D DLL will be garbage collected as you'd imagine. Obviously, it's not going to free any memory allocated in your C++ code ;)

I've written a C++ wrapper which communicates with D function but I have stumbled upon an error. With the code win32 DLL code on the digitalmars webpage (and yours) I receive linker errors: Error 42: Symbol Undefined _D4core10dll_helper18dll_process_detachFT4core3sys7w indows7windows6HANDLEbZv Error 42: Symbol Undefined _D4core10dll_helper18dll_process_attachFT4core3sys7w indows7windows6HANDLEbPvPvPvPiZb Error 42: Symbol Undefined _D4core13thread_helper12__ModuleInfoZ From my experience ModuleInfo undefined is often caused by not supplying a required source file to the linker, but since I only use functions from the library, I shouldn't be required to do that. Any tips?
Jul 18 2011
parent reply Loopback <elliott.darfink gmail.com> writes:
On 2011-07-18 21:59, Andrej Mitrovic wrote:
 import core.dll_helper; is outdated, use import core.sys.windows.dll;
 And also import core.runtime;

Are there any examples covering these new modules, or are the procedure the same?
Jul 18 2011
parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/18/2011 5:04 PM, Andrej Mitrovic wrote:
 On 7/18/11, Loopback<elliott.darfink gmail.com>  wrote:
 On 2011-07-18 21:59, Andrej Mitrovic wrote:
 import core.dll_helper; is outdated, use import core.sys.windows.dll;
 And also import core.runtime;

Are there any examples covering these new modules, or are the procedure the same?

It's all pretty much the same as the page says. There's a DLL example in this folder: \DMD\dmd2\samples\d\mydll

Looks like VisualD's DLL template needs to be updated. FWIW I was able to compile and link a D DLL with the code I copy pasted in the other message. Loopback, do you have Visual Studio on your dev box? If so you should take a look at VisualD: http://www.dsource.org/projects/visuald Let us know if you're not able to compile a D DLL.
Jul 18 2011
next sibling parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/18/2011 7:08 PM, Andrej Mitrovic wrote:
 On 7/19/11, Johann MacDonagh<johann.macdonagh.no spam.gmail.com>  wrote:
 FWIW I was able to compile and link a D DLL with the code I copy pasted
 in the other message.

Maybe you're running 2.052. I think in 2.053 dll_helper disappeared, and so in 2.054: D:\dev\code\d_code\DLLTest>dmd mydll.d mydll.d(9): Error: module dll_helper is in file 'core\dll_helper.d' which cannot be read

Oh wow, you're correct. I was missing with dvm and had an old version ;)
Jul 18 2011
prev sibling parent reply Loopback <elliott.darfink gmail.com> writes:
On 2011-07-19 00:56, Johann MacDonagh wrote:
 On 7/18/2011 5:04 PM, Andrej Mitrovic wrote:
 On 7/18/11, Loopback<elliott.darfink gmail.com> wrote:
 On 2011-07-18 21:59, Andrej Mitrovic wrote:
 import core.dll_helper; is outdated, use import core.sys.windows.dll;
 And also import core.runtime;

Are there any examples covering these new modules, or are the procedure the same?

It's all pretty much the same as the page says. There's a DLL example in this folder: \DMD\dmd2\samples\d\mydll

Looks like VisualD's DLL template needs to be updated. FWIW I was able to compile and link a D DLL with the code I copy pasted in the other message. Loopback, do you have Visual Studio on your dev box? If so you should take a look at VisualD: http://www.dsource.org/projects/visuald Let us know if you're not able to compile a D DLL.

Thanks for all of your replies! It seems as if the problem was solved by using core.sys.windows.dll instead. Although I do have a bit of a problem. As I mentioned earlier I wanted to make a DLL which C++ applications could interface with. By making this possible, I have a "dll.d" file (just as the example) and a "mydll.d" file - the file which implements the dll functions. In this file, I have declared a function like this (testing purpose): extern(C++) void SetInt(int * foo) { *foo = 5; } When I compile this program with this DMD command line: dmd -ofmydll.dll -L/IMPLIB mydll.d dll.d mydll.def I get a successful compile, and a DLL file generated. For some reason, I also get a ATA.lib file, which is exactly 1.00 KB big (any ideas why)? The problem though, is related to the C++ side. I load the DLL dynamically using "LoadLibraryA" function, and then I try to load the SetInt function using GetProcAddress. The LoadLibrary function succeeds but the GetProcAddress function call fails saying that the function could not be found. typedef void (*PFGMO)(int*); void main(int argc, char ** argv) { // Function Pointer PFGMO pFGMO = NULL; HINSTANCE library; if((library = LoadLibraryA("C:\\mydll.dll")) == NULL) throw 1; bool result = (pFGMO = (PFGMO) GetProcAddress(library, "SetInt")) != NULL; // Result is zero (failed) std::cout << "Result: " << result; std::cin.get(); } How come the procedure address cannot be found and how to solve it? If of interest, this is the .def file (mydll.def) LIBRARY "mydll.dll" EXETYPE NT SUBSYSTEM WINDOWS CODE SHARED EXECUTE DATA WRITE When viewing the DLL with PE Explorer (program to explore executable files) it reports that the number of symbols are zero. Is this related to the problem perhaps?
Jul 18 2011
next sibling parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/18/2011 10:40 PM, Andrej Mitrovic wrote:
 You have several problems.

 extern(C++) only specifies the calling convention, not the visibility
 of the symbol. To export the symbol, list it in a .def file or mark
 the function with export in the module itself, ala:

 export extern(C++) void SetInt(int * foo) {}

If you export it like this, it will be exported as the C++ mangled name. If you have extern(C) it will be cdecl "_SetInt" and extern(Windows) will be stdcall "_SetInt 4".
 I don't know why, but if you use a .def file instead of `export` the
 function will be exported as a C function with no name mangling.

If you look at dumpbin /exports you'll see something like this: ordinal hint RVA name 1 0 0000306C SetInt = ?SetInt YAXPAH Z (void __cdecl SetInt(int *)) So the symbol still has C++ name mangling but its exported as whatever name you want.
Jul 18 2011
parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/18/2011 11:52 PM, Andrej Mitrovic wrote:
 See I tried using dumpbin, but apparently I wiped it from my PATH so I
 had to rely on DLL Export viewer (because I'm lazy and it had an icon
 on my desktop!) which doesn't even show this. I had a hunch that was
 happening behind the scenes. Thanks for the info regardless hehe.

If you open a Visual Studio Command Prompt it should be in your PATH. Also, you won't see the internal symbol name unless you have pdb symbols in the same directory as the DLL (VisualD converts the symbols for me, which is why I saw it).
Jul 18 2011
prev sibling parent reply Loopback <elliott.darfink gmail.com> writes:
On 2011-07-19 04:40, Andrej Mitrovic wrote:
 You have several problems.

 extern(C++) only specifies the calling convention, not the visibility
 of the symbol. To export the symbol, list it in a .def file or mark
 the function with export in the module itself, ala:

 export extern(C++) void SetInt(int * foo) {}

 I don't know why, but if you use a .def file instead of `export` the
 function will be exported as a C function with no name mangling.

 Anyway, use a .def file like the one below and pass it to DMD while
 compiling the DLL, and it should be exported with that name (and
 change the string "mydll.dll" of course):

 LIBRARY         "mydll.dll"
 DESCRIPTION     'My DLL written in D'
 EXETYPE		    NT
 SUBSYSTEM       WINDOWS
 CODE            PRELOAD DISCARDABLE
 DATA            WRITE

 EXPORTS
      SetInt


 ATA.lib is probably the autogenerated import library which is useful
 for implicit linking.

I want to ask though how I am supposed to go about to enable class communication. For example; if I define a interface, and inherit this interface in a class, C++ can use these class functions by defining a analogous class (instead of interface) with virtual functions. If I create a class dynamically on the heap (in my dll), and then make a function that c++ can call to receive this object, how should I proceed then? extern(C++) interface Base { int Test(); } class Foo : Base { public: extern(C++) int Test() { return 5; } } export extern(C++) void GetObject(Base base) { Foo temp = new Foo; base = Foo; } This is just a example to explain what I want to accomplish. One problem with this code, is that a memory exception is thrown on the C++ side if this function is called, whenever I use the "new" operator. Is this because it's a export/extern function? // C++ Code class Base { public: virtual int Test(void); }; What is the best method to accomplish this, and are there any limitations with this method (do I have to allocate the class with malloc instead etc.)?
Jul 18 2011
parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/18/2011 11:27 PM, Loopback wrote:
 On 2011-07-19 04:40, Andrej Mitrovic wrote:
 You have several problems.

 extern(C++) only specifies the calling convention, not the visibility
 of the symbol. To export the symbol, list it in a .def file or mark
 the function with export in the module itself, ala:

 export extern(C++) void SetInt(int * foo) {}

 I don't know why, but if you use a .def file instead of `export` the
 function will be exported as a C function with no name mangling.

 Anyway, use a .def file like the one below and pass it to DMD while
 compiling the DLL, and it should be exported with that name (and
 change the string "mydll.dll" of course):

 LIBRARY "mydll.dll"
 DESCRIPTION 'My DLL written in D'
 EXETYPE NT
 SUBSYSTEM WINDOWS
 CODE PRELOAD DISCARDABLE
 DATA WRITE

 EXPORTS
 SetInt


 ATA.lib is probably the autogenerated import library which is useful
 for implicit linking.

I want to ask though how I am supposed to go about to enable class communication. For example; if I define a interface, and inherit this interface in a class, C++ can use these class functions by defining a analogous class (instead of interface) with virtual functions. If I create a class dynamically on the heap (in my dll), and then make a function that c++ can call to receive this object, how should I proceed then? extern(C++) interface Base { int Test(); } class Foo : Base { public: extern(C++) int Test() { return 5; } } export extern(C++) void GetObject(Base base) { Foo temp = new Foo; base = Foo; } This is just a example to explain what I want to accomplish. One problem with this code, is that a memory exception is thrown on the C++ side if this function is called, whenever I use the "new" operator. Is this because it's a export/extern function? // C++ Code class Base { public: virtual int Test(void); }; What is the best method to accomplish this, and are there any limitations with this method (do I have to allocate the class with malloc instead etc.)?

Your C++ class "Base" is not compatible with your D "Foo" class. The v-tables are not guaranteed to be identical. I'm not even sure if D's thiscall is the same as C++'s thiscall. It's just not going to work. Most languages don't support this. This is why we use C bindings. Everyone supports C ;) Now, you can do something like this: struct Foo { int x; float y; } extern(C) void* GetNewFoo() { // Note: Don't use new here otherwise the GC may clean it up return cast(void*) core.memory.GC.malloc(Foo.sizeof); } extern(C) float Foo_DoSomething(Foo* foo) { return foo.x + foo.y; } extern(C) void FreeFoo(Foo* foo) { core.memory.GC.free(foo); } I haven't tried this, but something like this should work. Structs are inherently compatible between languages. Of course, you won't be able to do any kind of polymorphism. Does this help?
Jul 18 2011
parent reply Loopback <elliott.darfink gmail.com> writes:
On 2011-07-19 05:46, Johann MacDonagh wrote:
 What is the best method to accomplish this, and are there any
 limitations with this method (do I have to allocate the class with
 malloc instead etc.)?

Your C++ class "Base" is not compatible with your D "Foo" class. The v-tables are not guaranteed to be identical. I'm not even sure if D's thiscall is the same as C++'s thiscall. It's just not going to work. Most languages don't support this. This is why we use C bindings. Everyone supports C ;) Now, you can do something like this: struct Foo { int x; float y; } extern(C) void* GetNewFoo() { // Note: Don't use new here otherwise the GC may clean it up return cast(void*) core.memory.GC.malloc(Foo.sizeof); } extern(C) float Foo_DoSomething(Foo* foo) { return foo.x + foo.y; } extern(C) void FreeFoo(Foo* foo) { core.memory.GC.free(foo); } I haven't tried this, but something like this should work. Structs are inherently compatible between languages. Of course, you won't be able to do any kind of polymorphism. Does this help?

Very interesting! This might help depends; are you able to have structures with functions? Are they still analogous if you implement them? Also, how come the class-interface inheritance didn't work to communicate with C++. Is the "Interface to C++" doc's outdated? "Calling D Virtual Functions From C++" http://www.digitalmars.com/d/2.0/cpp_interface.html
Jul 19 2011
parent Loopback <elliott.darfink gmail.com> writes:
On 2011-07-19 12:39, Loopback wrote:
 On 2011-07-19 05:46, Johann MacDonagh wrote:
 What is the best method to accomplish this, and are there any
 limitations with this method (do I have to allocate the class with
 malloc instead etc.)?

Your C++ class "Base" is not compatible with your D "Foo" class. The v-tables are not guaranteed to be identical. I'm not even sure if D's thiscall is the same as C++'s thiscall. It's just not going to work. Most languages don't support this. This is why we use C bindings. Everyone supports C ;) Now, you can do something like this: struct Foo { int x; float y; } extern(C) void* GetNewFoo() { // Note: Don't use new here otherwise the GC may clean it up return cast(void*) core.memory.GC.malloc(Foo.sizeof); } extern(C) float Foo_DoSomething(Foo* foo) { return foo.x + foo.y; } extern(C) void FreeFoo(Foo* foo) { core.memory.GC.free(foo); } I haven't tried this, but something like this should work. Structs are inherently compatible between languages. Of course, you won't be able to do any kind of polymorphism. Does this help?

Very interesting! This might help depends; are you able to have structures with functions? Are they still analogous if you implement them? Also, how come the class-interface inheritance didn't work to communicate with C++. Is the "Interface to C++" doc's outdated? "Calling D Virtual Functions From C++" http://www.digitalmars.com/d/2.0/cpp_interface.html

Are there any restrictions worth knowing or is it just like any other structure when D and C++ communicate? Can I have private variables, public, properties etc? And just not to forget, why the C++ and interface class didn't work?
Jul 19 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
import core.dll_helper; is outdated, use import core.sys.windows.dll;
And also import core.runtime;
Jul 18 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/18/11, Loopback <elliott.darfink gmail.com> wrote:
 On 2011-07-18 21:59, Andrej Mitrovic wrote:
 import core.dll_helper; is outdated, use import core.sys.windows.dll;
 And also import core.runtime;

Are there any examples covering these new modules, or are the procedure the same?

It's all pretty much the same as the page says. There's a DLL example in this folder: \DMD\dmd2\samples\d\mydll
Jul 18 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/19/11, Johann MacDonagh <johann.macdonagh.no spam.gmail.com> wrote:
 FWIW I was able to compile and link a D DLL with the code I copy pasted
 in the other message.

Maybe you're running 2.052. I think in 2.053 dll_helper disappeared, and so in 2.054: D:\dev\code\d_code\DLLTest>dmd mydll.d mydll.d(9): Error: module dll_helper is in file 'core\dll_helper.d' which cannot be read
Jul 18 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
You have several problems.

extern(C++) only specifies the calling convention, not the visibility
of the symbol. To export the symbol, list it in a .def file or mark
the function with export in the module itself, ala:

export extern(C++) void SetInt(int * foo) {}

I don't know why, but if you use a .def file instead of `export` the
function will be exported as a C function with no name mangling.

Anyway, use a .def file like the one below and pass it to DMD while
compiling the DLL, and it should be exported with that name (and
change the string "mydll.dll" of course):

LIBRARY         "mydll.dll"
DESCRIPTION     'My DLL written in D'
EXETYPE		    NT
SUBSYSTEM       WINDOWS
CODE            PRELOAD DISCARDABLE
DATA            WRITE

EXPORTS
    SetInt


ATA.lib is probably the autogenerated import library which is useful
for implicit linking.
Jul 18 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/19/11, Johann MacDonagh <johann.macdonagh.no spam.gmail.com> wrote:
 If you export it like this, it will be exported as the C++ mangled name.
 If you have extern(C) it will be cdecl "_SetInt" and extern(Windows)
 will be stdcall "_SetInt 4".

Right, that's all pretty standard stuff. :)
 I don't know why, but if you use a .def file instead of `export` the
 function will be exported as a C function with no name mangling.

If you look at dumpbin /exports you'll see something like this: ordinal hint RVA name 1 0 0000306C SetInt = ?SetInt YAXPAH Z (void __cdecl SetInt(int *)) So the symbol still has C++ name mangling but its exported as whatever name you want.

See I tried using dumpbin, but apparently I wiped it from my PATH so I had to rely on DLL Export viewer (because I'm lazy and it had an icon on my desktop!) which doesn't even show this. I had a hunch that was happening behind the scenes. Thanks for the info regardless hehe.
Jul 18 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Uhh, I tried using ASM to simulate the thiscall calling convention, it
didn't go all to well. :) A wrapper C++ DLL that exposes a C interface
was my workaround.

Here's a page that talks about some problems with passing objects via DLLs:
http://www.prowiki.org/wiki4d/wiki.cgi?BestPractices/DLL
Jul 18 2011