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

Reply via email to