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?

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