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

[Romain François]

On 01/02/2010 11:14 PM, Whit Armstrong wrote:
> 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?

I have not yet looked into vectors, so this part of the package is still 
as of Rcpp 0.7.0 using the interface that was here since the very 
beginning of Rcpp.

> 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.
>
> -Whit

There seems to be scope for collaboration indeed. Browsing around 
yesterday, I reminded myself of CXXR, which also has some overlap.

Although, CXXR has the grand ambition of refactoring all of R into C++, 
when we only seem to both provide convenience wrappers around existing R 
C infrastructure. I'll ping Andrew at some point.

Maybe it would be worth slowing down the commit rate on the code and 
work on some sort of design document. (although it usually take me 
longer to express things in words than in code).

Romain

-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/IW9B : C++ exceptions at the R level
|- http://tr.im/IlMh : CPP package: exposing C++ objects
`- http://tr.im/HlX9 : new package : bibtex