Comments on Sugar... Rcpp sugar seems to be an enhancement for C++ more than an interface function, so wouldn't it make sense to maintain it as a separate C++ class library? More generally, it would be useful to know what portions of Rcpp can function without the R engine running. This can be determined by trial and error, but it might be helpful if the boundary was more clearly defined. Another possible advantage is clients could link only against code that they really need. Thanks, Dominick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20101101/244a9e4f/attachment.htm>
[Rcpp-devel] Sugar
6 messages · Dominick Samperi, Shane Conway, Romain Francois +1 more
My two cents: That seems sensible; an alternative view would be to say that sugar is in the same vein as the rest of Rcpp, might regularly be used in the same code, and the goal should be to keep everything as simple as possible (i.e. one library). I, for one, don't see the need to separate them. They're very tightly coupled.
On Mon, Nov 1, 2010 at 1:13 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
Comments on Sugar... Rcpp sugar seems to be an enhancement for C++ more than an interface function, so wouldn't it make sense to maintain it as a separate C++ class library? More generally, it would be useful to know what portions of Rcpp can function without the R engine running. This can be determined by trial and error, but it might be helpful if the boundary was more clearly defined. Another possible advantage is clients could link only against code that they really need. Thanks, Dominick
_______________________________________________ Rcpp-devel mailing list Rcpp-devel at lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Le 01/11/10 06:13, Dominick Samperi a ?crit :
Comments on Sugar... Rcpp sugar seems to be an enhancement for C++ more than an interface function, so wouldn't it make sense to maintain it as a separate C++ class library?
not to me. sugar brings (parts of the) R syntax at the C++ level, it seems to me very appropriate where it is and it is not moving any time soon.
More generally, it would be useful to know what portions of Rcpp can function without the R engine running. This can be determined by trial and error, but it might be helpful if the boundary was more clearly defined.
I'm not interested in carrying out this study myself. Feel free to report what you find. I would believe that quite a large portion of the code needs R.
Another possible advantage is clients could link only against code that they really need.
Sugar is entirely templates and templates are only instanciated when used so the effect on the compilation time, etc ... is probably not that big a deal.
Thanks, Dominick
-- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube |- http://bit.ly/9P0eF9 : Google slides `- http://bit.ly/cVPjPe : Chicago R Meetup slides
Doesn't sugar require Rcpp vectors, which encapsulate R SEXP vectors? If that is the case you really cannot separate them at all since there is a direct dependency on R. -Andrew
On Mon, Nov 1, 2010 at 7:57 AM, Shane Conway <shane.conway at gmail.com> wrote:
My two cents: That seems sensible; an alternative view would be to say that sugar is in the same vein as the rest of Rcpp, might regularly be used in the same code, and the goal should be to keep everything as simple as possible (i.e. one library). I, for one, don't see the need to separate them. They're very tightly coupled. On Mon, Nov 1, 2010 at 1:13 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
Comments on Sugar... Rcpp sugar seems to be an enhancement for C++ more than an interface function, so wouldn't it make sense to maintain it as a separate C++ class library? More generally, it would be useful to know what portions of Rcpp can function without the R engine running. This can be determined by trial and error, but it might be helpful if the boundary was more clearly defined. Another possible advantage is clients could link only against code that they really need. Thanks, Dominick
_______________________________________________ Rcpp-devel mailing list Rcpp-devel at lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
_______________________________________________ Rcpp-devel mailing list Rcpp-devel at lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20101101/34fe5b30/attachment.htm>
Le 01/11/10 15:57, Shane Conway a ?crit :
My two cents: That seems sensible; an alternative view would be to say that sugar is in the same vein as the rest of Rcpp, might regularly be used in the same code, and the goal should be to keep everything as simple as possible (i.e. one library). I, for one, don't see the need to separate them. They're very tightly coupled.
They definitely are. The main magic behind sugar is the Rcpp::VectorBase template class that implements the necessary CRTP wizardry. classes such as NumericVector are derived from VectorBase, so Rcpp needs sugar. Also, order of imports matters and can get messy in C++. So I think users appreciate that we take care of it for them.
On Mon, Nov 1, 2010 at 1:13 AM, Dominick Samperi<djsamperi at gmail.com> wrote:
Comments on Sugar... Rcpp sugar seems to be an enhancement for C++ more than an interface function, so wouldn't it make sense to maintain it as a separate C++ class library? More generally, it would be useful to know what portions of Rcpp can function without the R engine running. This can be determined by trial and error, but it might be helpful if the boundary was more clearly defined. Another possible advantage is clients could link only against code that they really need. Thanks, Dominick
Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube |- http://bit.ly/9P0eF9 : Google slides `- http://bit.ly/cVPjPe : Chicago R Meetup slides
Le 01/11/10 16:00, Andrew Redd a ?crit :
Doesn't sugar require Rcpp vectors, which encapsulate R SEXP vectors? If that is the case you really cannot separate them at all since there is a direct dependency on R. -Andrew
It is more like both Rcpp vectors and sugar functions both depend on the same sugar magic classes (i.e VectorBase) Although sugar functions operating on lists (e.g. sapply) need to know about SEXP (which comes from the R API), so it is not as simple as on can make it sound to separate them. And again I'm not sure the benefit would really matter given the lazy instanciation of templates. One could do a version of Rcpp #ifdef'ing out sugar and report the diference e.g. in compilation time and size of executable, but not me as it does not sound like something I want to spend my time on. We do separate packages for things that use third-party code, e.g. RcppArmadillo or RcppGSL (to be released), but otherwise Shane's point about keeping it simple is a very valid point and a design principle we like to follow. Romain
On Mon, Nov 1, 2010 at 7:57 AM, Shane Conway <shane.conway at gmail.com
<mailto:shane.conway at gmail.com>> wrote:
My two cents:
That seems sensible; an alternative view would be to say that sugar is
in the same vein as the rest of Rcpp, might regularly be used in the
same code, and the goal should be to keep everything as simple as
possible (i.e. one library). I, for one, don't see the need to
separate them. They're very tightly coupled.
On Mon, Nov 1, 2010 at 1:13 AM, Dominick Samperi
<djsamperi at gmail.com <mailto:djsamperi at gmail.com>> wrote:
> Comments on Sugar...
>
> Rcpp sugar seems to be an enhancement for C++ more than an interface
> function,
> so wouldn't it make sense to maintain it as a separate C++ class
library?
> More generally, it would be useful to know what portions of Rcpp can
> function without the R engine running. This can be determined by
> trial and error, but it might be helpful if the boundary was more
> clearly defined. Another possible advantage is clients could link
only
> against code that they really need.
>
> Thanks,
> Dominick
Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube |- http://bit.ly/9P0eF9 : Google slides `- http://bit.ly/cVPjPe : Chicago R Meetup slides