[Rd] external pointers

[Roger Bivand]

On Mon, 12 Dec 2005 Mark.Bravington at csiro.au wrote:

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

One package using externalptr is rgdal - Tim Keitt wrote the bindings to
the external GDAL library for reading raster images to first return a
pointer to a dataset (on disk) opened by GDAL, then to use the object to
retrieve (parts of) the data. Most of the .Call/SEXP machinery is there
(for the C++ case, GDAL is C++, so GDAL manages its own memory for its
objects). The package also uses S4 classes, which may be overkill for your
purposes.

Roger

> 
> > 
> > Cheers,
> > Simon
> 
> bye
> Mark
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no