[Rcpp-devel] macros RCPP_FUNCTION_...,
Romain Francois
romain at r-enthusiasts.com
Tue Jun 18 21:05:45 CEST 2013
Le 18/06/13 19:50, Dirk Eddelbuettel a écrit :
>
> On 18 June 2013 at 16:26, Romain Francois wrote:
> | Hello,
> |
> | Who is using the macros RCPP_FUNCTION_0, ..., RCPP_FUNCTION_65, ...
> | (i.e. all the macros that live in the preprocessor_generated.h file).
> |
> | Their functionality is superseded by a much better way of doing it
> | (modules).
> |
> | I'd like to drop them at some point.
> |
> | Obviously it is not happening overnight, because for starters our own
> | RProtoBuf uses them. But I will update RProtoBuf so that it does not.
> | There is also uses in the RcppGSL vignette which I will update.
> |
> |
> |
> | The file spans >6000 lines of generated code that we could do without.
> | To put this into context, this represents about 10% of the lines of the
> | .h files in Rcpp.
> |
> | I don't think many people are using it, and I don't blame them. This was
> | an interesting idea when we introduced it, but we have something better now.
>
> Hm, I think my preference would be for a rather long period of deprecation --
> at least a year if not more -- before declaring it defunct.
For what it is worth. I just downloaded and unpacked source code for 113
packages using Rcpp, using a modified version of your runRcppDepends.
Then:
romain at naxos /tmp/stuff $ grep -r RCPP_FUNCTION *
RcppGSL/vignettes/RcppGSL/RcppGSL-intro.Rnw:% RCPP_FUNCTION_1( int,
sum_gsl_vector_int, RcppGSL::vector<int> vec){
RcppGSL/vignettes/RcppGSL/RcppGSL-intro.Rnw:% RCPP_FUNCTION_1( double,
gsl_vector_sum_2, Rcpp::List data ){
minqa/ChangeLog: * src/minqa.cpp: Expand RCPP_FUNCTION_X macros to make
debugging
So apart from:
- some vignette code that can easily be replaced by something using //
[[Rcpp::export]] and be much easier to understand.
- some comment in minqa
No one uses it.
Doing a long deprecating period over something nobody uses or care about
is a good way to forget to do it.
OTOH, removing them deals with the issue right now. We might get -ve
feedback from people who are in fact using it. In which case we can
propose to either
- fix their code using something simpler, easier to understand, better
- let them include the 6600 lines of clutter
Again, this code was a good idea when we made it, not anymore.
> Even then, maybe we should consider to not remove them as we have a good
> tradition of maintaining public APIs going forward. So my suggestion would be
> to deactivate them behind an #if with a new configuration #define in
> RcppConfig.
This is more clutter, we have to document this defined.
> APIs are contracts we have with users. I would prefer to see strong reasons
> for change, rather than a style preference.
This was just me stumbling upon the code and going: we don't need this
stuff anymore, let's get it out of the way.
If we keep it we surely need to document it as part of this contract you
mention.
> Now, 10% of code is of course a pretty good reason, but is it really making
> that much of a difference? The Rcpp package is large, and will remain large
> either way. An added #define should make compilaton faster which is good.
>
> Other views?
>
> Dirk
This is an opportunity for a quick diet. Just before the summer.
Of course it will stay big, see
http://gallery.r-enthusiasts.com/graph/Evolution_of_Rcpp_code_size_165
Anyway, too much time wasted already writing this email, but I remain
confident we can do something about that. We even managed to get the
classic api out of the way after all.
--
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