Re: [Rd] external pointers

From: Roger Bivand <Roger.Bivand_at_nhh.no>
Date: Mon 12 Dec 2005 - 07:54:49 GMT


On Mon, 12 Dec 2005 Mark.Bravington@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@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@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@nhh.no

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Mon Dec 12 19:00:30 2005

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