[Rcpp-devel] macros RCPP_FUNCTION_...,

Romain Francois romain at r-enthusiasts.com
Wed Jun 19 03:37:05 CEST 2013

Le 19/06/13 02:33, Darren Cook a écrit :
>> This is an opportunity for a quick diet. Just before the summer.
> Looking good in a bikini is always important. :-)

glad you enjoyed the visual

> That no-one uses it in any CRAN package is also compelling. (I just
> searched on StackOverflow and no mention there either.)
> Dirk wrote:
>>> APIs are contracts we have with users.  I would prefer to see strong
>>> reasons for change, rather than a style preference.
> Romain wrote:
>> If we keep it we surely need to document it as part of this contract
> I think this is the most compelling reason. It seems almost undocumented.
> https://www.google.co.jp/search?q="RCPP_FUNCTION"
> https://www.google.co.jp/search?q="RCPP_FUNCTION_0"
> There is something here:
>   http://dirk.eddelbuettel.com/blog/2010/05/17/
> (BTW, shouldn't "RCPP_FUNCTION_VOID_2" have been "RCPP_FUNCTION_VOID_1" ?)

yes. so the single very well hidden bit of documentation we have about 
this is wrong.

> Can those examples be mechanically converted to use Rcpp modules,
> Romain?

I'm not writing mechanics for something that is never going to be used.

What do you want to see:

- this:

RCPP_FUNCTION_2( int, foobar, int x, int y){
	    return x + y ;

or this:

// [[Rcpp::export]]
int foobar( int x, int y){
     return x + y ;

The attributes feature is awesome. Anyone who reads c++ can understand 
what goes on. Not the same story with the macro.

I know their value, I wrote the code. I know what they are for. But we 
don't need them anymore.

> If so, documenting how to convert might be sufficient, and
> anyone who gets hit by the removal can spend 20 minutes updating their
> code to work.
> Darren

Yes. And I'm happy to so it for every single one of them. Of course, I'm 
not taking a big risk because nobody uses this.

If we leave the code as it is, the hypothetical user that does not exist 
is happy.

If we remove it, the same hypothetical user is first going to get upset, 
and then he will be happy to have better code when I have fixed it.

For everyone else, they are going to have an Rcpp with less clutter and 
a better ratio of [stuff that is in the package] / [stuff that is 

This in my view is positive. Of course eventually I don't care all that 
much. This was just a random idea.

Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

R Graph Gallery: http://gallery.r-enthusiasts.com

blog:            http://blog.r-enthusiasts.com
|- http://bit.ly/Zs97qg  : highlight 0.4.1
`- http://bit.ly/10X94UM : Mobile version of the graph gallery

More information about the Rcpp-devel mailing list