On Mon, 12 Dec 2005 [EMAIL PROTECTED] wrote: > Hi Simon > > Thanks for that... see below for my feeble counterblasts! (And two > questions.) > > > Mark, > > > > On Dec 12, 2005, at 7:48 AM, <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
