• Jarrett Billingsley (26/26) May 01 2005 I'd like to design a DLL in D that will present a C interface for use in...
• Andrew Fedoniouk (6/33) May 01 2005 "don't return pointers to GC-allocated memory to the caller"

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

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? 

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"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?