Mark, On Dec 12, 2005, at 7:48 AM, <[EMAIL PROTECTED]> 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
