external pointers

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

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.

On Mon, 12 Dec 2005, Roger Bivand wrote:

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.

RODBC is another, somewhat simpler, one.

There is documentation on developer.r-project.org, but my  
recollection is
that is was not up to date (and in particular not re finalizers).   
On my
TODO list is to add end-user documentation to `Writing R Extensions'.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

There's also Luke's own site, in particular http://www.stat.uiowa.edu/ 
~luke/R/weakfinex.html

On Dec 12, 2005, at 12:16 AM, Prof Brian Ripley wrote:

On Mon, 12 Dec 2005, Roger Bivand wrote:

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.

RODBC is another, somewhat simpler, one.

There is documentation on developer.r-project.org, but my recollection is
that is was not up to date (and in particular not re finalizers).  On my
TODO list is to add end-user documentation to `Writing R Extensions'.