[Rcpp-devel] RFC: Rcpp modules vs. RefClass
xian at unm.edu
Mon Dec 5 11:10:54 CET 2016
On Wed, Nov 30, 2016 at 8:23 AM, Whit Armstrong <armstrong.whit at gmail.com>
> My point regarding the clang parser is that one really shouldn't have to
> write any R or Rcpp wrappers at all.
I realize this is a bit academic, but I suppose my position reduces to
"RefClass + Rcpp = no wrappers at all".
For many (most?) people, a central point of Rcpp is to A) make things
faster with minimal effort while B) still use R. RefClasses add native
reference semantics to R, and one motivation for my original question is
their relative newness. Indeed, it looks like JMC did a big doc rework
this Sept (
Of course, RefClasses aren't as rich in, er, nuance as Cpp classes, but
that may be a feature for many folks.
With this in mind, I assert that using a RefClass to define an object's
data & methods, and then pushing "expensive" functionality to Cpp via Rcpp
attributes, is the minimum possible "effort" required to (for expensive and
effort suitably defined): A) achieve by-reference semantics using B)
compiled-language speedup that C) doesn't mutate the args of user-facing
One annoyance using the RefClass + Rcpp approach is messy argument passing.
With the Rcpp modules approach, Cpp data members of course need not be
passed to Cpp member functions (though some still had to be set via R, of
course). With a RefClass, one possibility is to prepare one or more named
lists to pass to Rcpp functions. These lists then, kinda-sorta, fill the
role of a cpp class's self pointer.
I wrote up a minimal example to verify that this approach isn't too costly.
It's too painfully simple to test *much*, but it perhaps provides a useful
For production code, my thought is to prep the relevant lists during
initialize() and then lock() them... I haven't gotten there yet :)
A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rcpp-devel