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.con...@gmail.com
<mailto:shane.con...@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
<djsamp...@gmail.com <mailto:djsamp...@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
_______________________________________________
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