Re: [Rd] external pointers

From: <>
Date: Mon 12 Dec 2005 - 07:37:54 GMT

Hi Simon

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

> Mark,
> On Dec 12, 2005, at 7:48 AM, <> 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

Mark mailing list Received on Mon Dec 12 18:45:13 2005

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:34 GMT