[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