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 ;)

Thank you for your reply!

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?

Reply via email to