[Rcpp-devel] follow up from: Re: [Rd] R_PreserveObject, R_ReleaseObject : reference counting needed ?

Whit Armstrong armstrong.whit at gmail.com
Sat Jan 2 23:14:46 CET 2010

Romain and Dirk,

> Our main class is Rcpp::RObject that wraps any SEXP into a C++ object that
> basically R_PreserveObject when it is created, and R_ReleaseObject when the
> object is destroyed.
> deriving from "RObject", we have "Environment" to deal specifically with
> environments (ENVSXP) , "Symbol" to deal with symbols (SYMSXP), "Language"
> for calls (LANGSXP) and the template XPTr for external pointers. The rest
> (vectors, functions, ...) will follow.

I see, so you all seem to be maintaining the existing interface, but
moving forward in a different direction with a proper c++ object based
set of classes.

I'll definitely keep following the changes, I would like to see all
the cpp packages come together at some point.  I also found this one
today: http://r-forge.r-project.org/projects/rcppbind.

There are two differences between Rcpp and what I've done w/
RAbstraction.  One, is the reference counting.  To me it seems like
the easiest way to get out of the whole PROTECT/UNPROTECT mess.  The
second is that I chose to base the template parameters on SEXPTYPE
rather than c++ types (double, int, bool). The main reason was that
LOGICALS are represented as ints in R, and if you declare a bool
RcppVector, then how do you put an NA into it?

My biggest regret about the design is that I didn't make a proper
inheritance tree.  My new project (RObjects) tries to solve this by
making everything inherit from RObject and having pure virtual base
classes for vector and matrix so that all the type specific classes
can use the same interface.

Anyway, both of our projects seem to be changing quickly at the
moment.  Let me know if you all see an opportunity to merge at some
point.  I do think all of these splintering c++ projects is not good
for encouraging c++ usage within R.


More information about the Rcpp-devel mailing list