Le 17 avr. 2014 à 09:42, Hao Ye <h...@ucsd.edu> a écrit :

> Hi Romain,
> 
> Thanks for the explanation -- I was curious about the difference between Rcpp 
> and Rcpp11, as well.
>  
> What might help you deciding is that in Rcpp11, we did not retain some 
> features such as modules and date/time related classes. If your code uses 
> these, then you should probably either stick with Rcpp or start motivating me 
> for adding something along the lines in Rcpp11. There is still a need for 
> something like modules, but not with this implementation.
> 
> Does this mean that there will be some other mechanism for exposing c++ 
> classes to R? Maybe in some way that supports inheritence? ;)

Yes. Problems with Rcpp modules are: 
  -  the way you express things is limited by C++ grammar. It was fun and 
challenging to write it. But experience of teaching modules shows that the 
concepts are somewhat hard to grasp. 
  - it is very demanding in terms of resources

In the future, I’d like to look into code generation (a la attributes) as a 
mean of exposing classes. So we need something expressive enough. My current 
blue sky line of thinking about this is that I’d like to have some sort of 
intermediate language between R and C++. John has done something similar with 
the exposeClass in Rcpp. 
https://github.com/RcppCore/Rcpp/blob/master/R/exposeClass.R

It goes in the right direction, but this time you are limited by R’s grammar. 
This has been on my radar for some time, but I think having a class system that 
is nice to use in R requires some grammatical changes. It is unlikely that I 
will have the leverage to change R’s grammar, but what I can work on is an 
intermediate language that generates R code. 

In any case, Rcpp11 still has the external pointer class template, so we can « 
write modules by hand ». 

Romain

_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to