[Rcpp-devel] Registering a custom delete_finalizer for my XPtrs

Dirk Eddelbuettel edd at debian.org
Tue Jul 5 04:08:55 CEST 2011


Hi Steve,

Thanks for the nicely detailed email which was very well reasoned.  I'll be
brief as I just got back from Europe and am a little fried from
travelling. But if I don't reply now it may fall to the wayside...

On 4 July 2011 at 10:09, Steve Lianoglou wrote: 
| On Mon, Jul 4, 2011 at 4:00 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
| Yeah, I'm actually writing a third/custom wrapper that talks straight
| to the "core" shogun c++ library (not a SWIG wrapped something).

[shogun details omitted]

| With my library, it's more of what an R user would expect, eg:
| 
| svm <- SVM(traindat, trainlab, kernel='gaussian', width=40, C=10)
| predict(svm, ...)

Totally agreed. That's what we'd want in the long run!
 
| > I guess you also looked into altering their wrapper?
| 
| I did -- I also thought about just wrapping their wrappers, but (i) I
| don't think I could make it as flexible as I would like; (ii) there is
| actually some problem with swig in R-land that (I think) causes a

Correct. The one dude working on Swig for R actually used it for QuantLib so
he get very deep into R internals mojo. That said, I only once got his
R/QuantLib SWIG bindings built, and he seems to float away from maintaining
for extended periods. So I don't do Swig either -- hence Rcpp and possibly
more manual approaches.

| > You could use our XPtr class instead too.  I do so in RcppDE to wrap a
| > pointer to a user-supplied C function.
| 
| I do use it (XPtr mojo) when I'm "unwrapping" a pointer to an object
| that was sent back to C++ from R, but I don't know how to use it the
| first time -- ie, when I finish building the shogun object for the
| first time and package it up to send back to R-land (for later use)
| since I need this custom 'on delete' function.
| 
| I poked around in the RcppDE source but couldn't find an example of
| that particular use case -- perhaps I missed it?

It is in src/evaluate.h and contained in a pretty small class layer that
generalises how a user-defined utility function is being brought in. Either
as an R function, or via XPtr as a C function. Might well be too simple an
example for you. Also no ref counting and all that.
 
| > But where would the logic to deal with 'SomeShogunObject' come from?
| 
| I've already written it, the "destruction" of all shogun object are
| the same, and is already written in my `_shogun_ref_count_down`
| function I am currently registering like so:
| 
| R_RegisterCFinalizer(xp, _shogun_ref_count_down)

Ack.  If the XPtr leaves the object alone (as it should) then
R_RegisterCFinalizer may be appropriate.   Might be best to test on a really
small and self-contained example.
 
| > Because the persistence stuff is harder.  It helps to know the other projects
| > internals well enough.  So my advice would be to keep the fancy stuff for
| > 'version 2.0'.  Unless you have plenty of time to learn and try fancy things.
| 
| Yeah -- it's good advice, actually ...

Same for external pointer objects and getting lifetimes and memory management
right.  If you get the basics right, the rest 'should' be easy :)
 
| Would it be possible to overload the XPtr::setDeleteFinalizer function
| so it has a version that takes a function pointer? So I could do
| something like:
| 
| Rcpp::XPtr<SomeShogunObject> so(new SomeShogunObject(what,ever), false);
| so->setDeleteFinalizer(&my_finalizer_function);
| 
| (I don't know if that's the correct syntax to pass functions around(?))

Dunno. Possibly. Romain may know, but not sure if he currently reads the list.
 
| > In a way Rcpp modules is orthogonal, and also more restricted (but easier for
| > simple connections to libraries).
| 
| Indeed -- as I was reading over it more, I don't think RcppModules
| would fit here since (i) there are lots of overloaded methods for
| shogun classes I'd need to "wire"; and (ii) shogun has pretty deep
| class hierarchies (and I think "inheritance" is part of the "Future
| extensions" of the RcppModules, anyway).

Correct on all counts.
 
| > Hope this helps,  Dirk
| 
| Yup -- thanks for taking the time to chew on the email.
 
Pleasure!  It is pretty neat to see Rcpp pop up in exciting places like this.

Cheers, Dirk

-- 
Gauss once played himself in a zero-sum game and won $50.
                      -- #11 at http://www.gaussfacts.com


More information about the Rcpp-devel mailing list