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?

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.

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

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?

import core.dll_helper; is outdated, use import core.sys.windows.dll; And also import core.runtime;

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?

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

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.

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

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