I don't entirely follow Ross's outline below (?how does the R object 'opaque' get to feature in the call to 'docompute'?), but I have written large amounts of R-linked Delphi code with persistent Delphi objects, using only the '.C' interface and no external pointers. You might find this useful if you want to avoid the complexities of '.Call' and SEXPs etc. NB the C/Delphi distincition is not important here.
(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. (ii) For subsequent '.C' calls to Delphi from R, I pass in the handle, which I then typecast to an object pointer inside Delphi. Hence I can "find" the persistent object. This way there can be several persistent objects simultaneously-- I'm not limited to global variables in the Delphi DLL. (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. I have also gotten this to work after replacing Delphi's memory manager with R's own-- there was no difference (but apparently no point either, from what I've been told). There are some further notes inside a PDF on Duncan Murdoch's page: http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/pascal.ht ml The notes are very Delphi-flavoured (and refer to S not R, since I've used the method both with S-plus and R) but the point should-- or might-- be clear. HTH Mark Mark Bravington CSIRO Mathematical & Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Byron Ellis > Sent: Saturday, 10 December 2005 11:24 AM > To: Ross Boylan > Cc: R Development List > Subject: Re: [Rd] external pointers > > use a C finalizer... > > void MyObject_finalize(SEXP opaque) { > MyObject *obj = (MyObject*)R_ExternalPtrAddr(opaque); > if(NULL != obj) delete obj; > } > > and in your setup code... > > PROTECT(p = R_MakeExternalPtr(...)); > R_RegisterCFinalizer(p,MyObject_finalize); > > > > > > > On Dec 9, 2005, at 3:04 PM, Ross Boylan wrote: > > > I have some C data I want to pass back to R opaquely, and > then back to > > C. I understand external pointers are the way to do so. > > > > I'm trying to find how they interact with garbage collection and > > object lifetime, and what I need to do so that the memory > lives until > > the calling R process ends. > > > > Could anyone give me some pointers? I haven't found much > > documentation. > > An earlier message suggested looking at simpleref.nw, but I > can't find > > that file. > > > > So the overall pattern, from R, would look like opaque <- > setup(arg1, > > arg2, ....) # setup calls a C fn docompute(arg1, argb, opaque) # > > many times. docompute also calls C # and then when I return > opaque and > > the memory it's wrapping get #cleaned up. If necessary I could do > > teardown(opaque) # at the end > > > > "C" is actually C++ via a C interface, if that matters. In > > particular, the memory allocated will likely be from the > C++ run-time, > > and needs C++ destructors. > > > > -- > > Ross Boylan wk: (415) 514-8146 > > 185 Berry St #5700 > [EMAIL PROTECTED] > > Dept of Epidemiology and Biostatistics fax: (415) 514-8150 > > University of California, San Francisco > > San Francisco, CA 94107-1739 hm: (415) 550-1062 > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > --- > Byron Ellis ([EMAIL PROTECTED]) > "Oook" -- The Librarian > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
