From simon.urbanek at r-project.org  Mon Dec 12 05:38:54 2005
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Mon, 12 Dec 2005 13:38:54 +0900
Subject: [Rd] external pointers
In-Reply-To: <D79013E40FEF254AAF0D72DFC94F274803D957@extas4-hba.tas.csiro.au>
References: <D79013E40FEF254AAF0D72DFC94F274803D957@extas4-hba.tas.csiro.au>
Message-ID: <1DA96B7D-F52C-49AB-A109-9186E3E694C7@r-project.org>

Mark,

On Dec 12, 2005, at 7:48 AM, <Mark.Bravington at csiro.au> wrote:

> (i)The first '.C' call uses Delphi code to allocate (using Delphi's  
> own memory manager) and set up a persistent object that R doesn't  
> know about. The Delphi code then returns an "opaque" integer-valued  
> handle to R, which is the address of the object in the Delphi DLL's  
> world.

That's a bad idea for a couple of reasons, the main being that  
integer is not guaranteed to be able to hold a pointer - it won't  
work on any 64-bit platform. Second drawback is that you have no way  
to link the life of the R object to your Delphi object, because there  
is no way gc will tell you that the object is gone. This will lead to  
memory leaks. [Been there, done that ;)] Both issues are solved by  
the external pointers.

> (iii) There is a final cleanup '.C' call which deallocates the  
> persistent object. I sometimes also automate the destruction in the  
> cleanup code of the DLL, just in case the R user forgets to cleanup.

How do you make sure the no one uses the now invalid integer value?  
There can be many copies of your proxy object around and they all  
point to nirvana ...

Cheers,
Simon



[Rd] external pointers
Simon Urbanek