From Mark.Bravington at csiro.au  Mon Dec 12 08:37:54 2005
From: Mark.Bravington at csiro.au (Mark.Bravington@csiro.au)
Date: Mon, 12 Dec 2005 18:37:54 +1100
Subject: [Rd] external pointers
Message-ID: <D79013E40FEF254AAF0D72DFC94F274803D95C@extas4-hba.tas.csiro.au>

Hi Simon

Thanks for that... see below for my feeble counterblasts! (And two
questions.)

> 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. 

Very true, though 64 bit systems are not a big worry for Delphi 6.0
writers... ;) I did once speculate about hacking around this sort of
thing by encoding into character strings instead of integers, uggg.

> 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 ...

Sorry, that was lack of clarity on my part about what I meant by
"persistent". Whenever I use this mechanism, I'm careful to ensure that
the C/Delphi objects only have lifetimes *within* a function, and to
include an 'on.exit' call to the "destructor"-- I would never  create
global objects pointing to ephemeral C structures. Admittedly, this
relies on programming self-discipline, and has no cast-iron anti-nirvana
mechanism! Ross' original query seems very much along these lines,
though.

If I was really creating global persistent objects, then 'externalptr'
would definitely be much better.

Where would be best to read about externalptr? I'm having trouble
finding material in the manuals or the site-search.

And would I need to use all the .Call machinery and C headers and SEXP
etc in order to handle externalptr objects?

> 
> Cheers,
> Simon

bye
Mark



[Rd] external pointers
Mark.Bravington@csiro.au