> > (I guess one downside of Rcpp modules is the use of external pointers, > which implies they do not serialize / deserialize well?)
I think not at all, unless you can force the same memory location for a new R session and everything it loads. This is documented in the Rcpp-modules vignette -- I tried it anyway, and it crashed my R session. :) Best, -- Hao Ye h...@ucsd.edu On Tue, Nov 29, 2016 at 11:02 AM, Kevin Ushey <kevinus...@gmail.com> wrote: > To be brief -- Rcpp modules are effectively in maintenance mode at this > point; we don't plan to extend / improve modules beyond resolving issues if > and when they come up. We did get to the bottom of the posted issue -- R > packages that use modules need to import the whole Rcpp namespace. > > I'm not quite sure what the parallel between reference classes and modules > are here -- Rcpp modules allow you to basically expose C++ classes to R > with a relatively minimal amount of boilerplate; of course you can write > your own R functions (maybe as part of a reference class) to do the same, > but the techniques are in the end different. > > In sum, I think Rcpp modules are more geared towards developers who are > primarily C++ programmers who just want a super-simple way to expose a C++ > class to R; other methods are going to lean towards being more R-centric. I > can't really call one method 'better' or 'worse'; they're just different. > (I guess one downside of Rcpp modules is the use of external pointers, > which implies they do not serialize / deserialize well?) > > Kevin > > On Mon, Nov 28, 2016 at 8:40 PM, Christian Gunning <x...@unm.edu> wrote: > >> Dear List, >> >> The following is a general request for advice / comment on modern Rcpp >> development best-practices for package & class development. I looked over >> the Rcpp gallery, and didn't see anything obvious that answers my >> questions - perhaps this discussion could serve as a prototype for a new >> post? >> >> ## Background >> >> I've used Rcpp modules for several projects where in-place modification >> was required for performance reasons. I like the interface - it encourages >> clean code, and yields a nice mix of performance and encapsulation. >> >> In the past, the lack of serialization has been a minor annoyance. >> Honestly, it's not something I need, but I dislike having invalid objects >> in the work-space after a quit/restart. I've spent a little time thinking >> about work-arounds, which essentially boil down to moving back and forth >> from an R list object. >> >> Looking towards the future, I also looked at the recent Rcpp dev history. >> It looks like modules has had some maintenance issues - for example, the >> last edits there (i..e, PR 454) were reverted due to Windows toolchain >> issues (i.e., https://github.com/RcppCore/Rcpp/issues/463). From my >> outside perspective, it appears that the modules code is A) hard, and B) >> not a current dev priority. >> >> ## A possible alternative: RefClass >> >> I'm able to achieve similar behavior (in-place modification using named >> methods, relatively tidy code) using a combination of R RefClasses and Rcpp >> attributes. This solves the issue of serialization, and yields reasonably >> clean code. This has the added benefit of allowing easy mixing of R and C++ >> code in class methods. >> >> From a user perspective, RefClass methods are a nice place for Rcpp >> functions that modify args in-place, since RefClass implies side-effects. >> And, in terms of style, if all C++ method functions return void, and have >> const-correct arglists, then the C++ function signatures provide something >> of a interface spec. >> >> Minimal example: >> https://gist.github.com/helmingstay/17d5d9f241c4170a29d1681db0111065 >> >> >> ## Summary of observations: >> >> * RefClass + attributes achieves similar outcomes to Rcpp modules, with >> somewhat better support (serialization, documentation, future?). >> >> * Unique to Rcpp modules is the ability to auto-magically generate >> RefClass-like R bindings for existing C++ class-based code. >> >> * For "mere mortals", Rcpp modules now look less attractive for routine >> use, given available alternatives (i.e. for anything but binding >> auto-generation) >> >> >> ## Questions: >> >> A) Any obvious problems with the above observations? >> >> B) Are there any *gotchas* with using Rcpp "modify-in-place" functions >> inside RefClass methods? >> >> C) Is anyone else doing this? Any suggested improvements on the above? >> >> Thanks much, >> Christian Gunning >> -- >> A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama! >> >> _______________________________________________ >> 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 >> > >
_______________________________________________ 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
