Have a look at this project: https://github.com/richfitz/RcppR6
On Mon, Nov 28, 2016 at 11: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
