|Posted by Andrew Fedoniouk|
in reply to Jarrett Billingsley
Posted in reply to Jarrett Billingsley
"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.
"Jarrett Billingsley" <firstname.lastname@example.org> wrote in message news:email@example.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?