[Rcpp-devel] Registering a custom delete_finalizer for my XPtrs
edd at debian.org
Tue Jul 5 04:08:55 CEST 2011
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);
| (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.
Gauss once played himself in a zero-sum game and won $50.
-- #11 at http://www.gaussfacts.com
More information about the Rcpp-devel