On 12 June 2014 at 17:48, Martin Jakt wrote: | Hi Fernando and list members, | | > For my purposes, I think I could use S4 objects that make C++ copies of | > themselves at creation time, accessible via an external pointer. All | > methods would then make use of the C++ copies for speed, and at the end | > of the session the S4 copies that live in the R side would be saved. | | I'm wondering how you've gotten on with this. I'm struggling with a somewhat | similar problem in my own package. This uses the 'Rcpp modules' to provide an | interface to a couple of C++ functions. This works very well, but accessing | the objects (created by new()) after a save/reload cycle results in R | crashing.
It is a known shortcoming. | I don't really mind to lose the information within the objects and am just | looking for some way to avoid R trying to access invalid pointers after a | reload. My thought was to somehow subvert the 'save' process such that the | pointer address is not written. Can this be done? I tried to set the | serialize() function for the class, but this seems not to be used by save(). I think this is the right route. And we now have access to serialize() from the C/C++ side (via the small package RApiSerialize which I used in RcppRedis). It should not be too hard to move towards something like saveRDS/readRDS. Maybe you can experiment with explicitly deserialization of the 'payload' of your object, and then recreate it? | The behaviour I would be happy with, is something similar to what you get with | RMySQL connections. These (understandably) get dropped between sessions, and | need to be recreated by calling the constructor. | | I would appreciate any advice or pointers. I've tried searching the | documentation for answers, but have failed to find anything that I can find. There were some old discussions when Modules was new and fresh, but nobody has worked out a solution. It should be doable, though, or at least "approximatively". But we can rely on just 'save' or 'saveImage'. We need to do the extra step. | I'd also like to say that I _really_ appreciate Rcpp, especially the sourceCpp | function; it's makes R comfortable to use. Thanks to the developers. Thanks for the kind words. Many of us use it too :) Dirk | Martin | | -- | Martin Jakt | Department of Systems Medicine | Mitsunada Sakaguchi Laboratory | Keio University School of Medicine | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel@lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
