[Rcpp-devel] Sugar

[Romain Francois]

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