View mode: basic / threaded / horizontal-split · Log in · Help
May 01, 2005
Designing a DLL for a non-GC language
I'd like to design a DLL in D that will present a C interface for use in 
another language.  Here's what it will do:

1) It has a class.
2) The caller can create instances of the class, and will hold on to the 
handle of the class.  The DLL will keep track, internally, of all instances 
of this class.
3) The caller can call methods of the class.
4) The caller can delete instances of the class.

Points 2, 3, and 4 are all handled through C-style functions (no ABI support 
for D in the other language).

What I'm wondering is if this is legal with the GC.

The D DLL doc says:

"Retain a pointer to the data within the D DLL so the GC will not free it. 
Establish a protocol where the caller informs the D DLL when it is safe to 
free the data."

I do that with the internal array and with the function that tells the DLL 
to free the memory.  However, the following statement seems contradictory:

"Do not return pointers to D gc allocated memory to the caller of the DLL. 
Instead, have the caller allocate a buffer, and have the DLL fill in that 
buffer."

So it says, "keep a pointer to GC-allocated memory in the DLL," but it also 
says "don't return pointers to GC-allocated memory to the caller"?  If the 
memory is pointed to by the DLL, wouldn't it then be safe to return a 
pointer to the caller, as the GC wouldn't be able to free it?  What if the 
caller doesn't have access to the standard C free() function and can't free 
the memory without the help of the DLL?
May 02, 2005
Re: Designing a DLL for a non-GC language
"don't return pointers to GC-allocated memory to the caller"
It is recommendation - good behavior in all cases. Not only specific to D.
E.g. the whole Win32 API is based on this principle.

Andrew.




"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message 
news:d52m3a$2kjt$1@digitaldaemon.com...
> I'd like to design a DLL in D that will present a C interface for use in 
> another language.  Here's what it will do:
>
> 1) It has a class.
> 2) The caller can create instances of the class, and will hold on to the 
> handle of the class.  The DLL will keep track, internally, of all 
> instances of this class.
> 3) The caller can call methods of the class.
> 4) The caller can delete instances of the class.
>
> Points 2, 3, and 4 are all handled through C-style functions (no ABI 
> support for D in the other language).
>
> What I'm wondering is if this is legal with the GC.
>
> The D DLL doc says:
>
> "Retain a pointer to the data within the D DLL so the GC will not free it. 
> Establish a protocol where the caller informs the D DLL when it is safe to 
> free the data."
>
> I do that with the internal array and with the function that tells the DLL 
> to free the memory.  However, the following statement seems contradictory:
>
> "Do not return pointers to D gc allocated memory to the caller of the DLL. 
> Instead, have the caller allocate a buffer, and have the DLL fill in that 
> buffer."
>
> So it says, "keep a pointer to GC-allocated memory in the DLL," but it 
> also says "don't return pointers to GC-allocated memory to the caller"? 
> If the memory is pointed to by the DLL, wouldn't it then be safe to return 
> a pointer to the caller, as the GC wouldn't be able to free it?  What if 
> the caller doesn't have access to the standard C free() function and can't 
> free the memory without the help of the DLL?
>
Top | Discussion index | About this forum | D home