external pointers

Mark,

(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