[Rcpp-devel] RFC: Rcpp modules vs. RefClass

Christian Gunning xian at unm.edu
Tue Nov 29 05:40:55 CET 2016

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

## 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:

## 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

## 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20161128/65d7bb99/attachment.html>

More information about the Rcpp-devel mailing list