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

Whit Armstrong armstrong.whit at gmail.com
Wed Nov 30 16:23:04 CET 2016

My point regarding the clang parser is that one really shouldn't have to
write any R or Rcpp wrappers at all.

If one directly parses the c++ class then both the R6/RefClass/List (or
whatever implementation one chooses to use) and the C wrappers (which we
will still need as we can't expose the c++ class directly to R; we still
need .Call) can be generated directly from parsing the class w/ clang.

Rcpp modules uses chaining to do this, but one still has to write this code:

        .constructor("default constructor")
        .constructor<std::string>("constructor with host port")
        .constructor<std::string, int>("constructor with host and port")
        .constructor<std::string, int, std::string>("constructor with host
and port and auth")
        .constructor<std::string, int, std::string, int>("constructor with
host and port, auth, and timeout")
        .method("exec", &Redis::exec,  "execute given redis command and

richfitz/RcppR6 uses some yaml to generate the bindings, which one has to
provide and keep it synchronized w/ the class.

    args: [radius: double]
      return_type: double
      name_cpp: circumference
      name_cpp_set: set_circumference
      access: member
      type: double
    radius: {access: field, type: double}

we should be able to extract all that from the class itself w/ clang.
That's the point.


On Wed, Nov 30, 2016 at 5:49 AM, Christian Gunning <xian at unm.edu> wrote:

> Whit,
> I see that this could be useful in similar situations where Rcpp modules
> excels (generating R bindings to existing C++ classes). Language preference
> aside, it's less clear to me what advantage this approach (or Rcpp modules)
> offers average users over RefClasses + Rcpp functions, where the RefClass
> holds state, and the Rcpp functions operate on the state using by-reference
> semantics.
> -Christian
> On Tue, Nov 29, 2016 at 5:33 AM, Whit Armstrong <armstrong.whit at gmail.com>
> wrote:
>> Have a look at this project:
>> https://github.com/richfitz/RcppR6
>> On Mon, Nov 28, 2016 at 11:40 PM, Christian Gunning <xian at 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 at lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> --
> 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/20161130/8b2a6a48/attachment.html>

More information about the Rcpp-devel mailing list