[Rcpp-devel] Rcpp 0.10

JJ Allaire jj.allaire at gmail.com
Thu Nov 15 20:18:40 CET 2012


> 1. Suggestion: it might be appropriate to say (probably before 5.1) that
> Makevars, etc, are still needed. And, thus, point the reader to
> vignette("Rcpp-package").
>

Very good suggestion -- will do!


> I mean, the .h and *.R files generated with Rcpp.package.skeleton seem to
> have a simple structure that I find easy to replicate and modify as I keep
> adding stuff to my *.cpp file.  (For instance, the placement of RccpExport
> before functions intended to be exported, the usage of SEXP,
> etc). However, I do not clearly see how to go around the files generated
> by compileAttributes and how to mix that with .R and *.h files previously
> generated with Rcpp.package.skeleton. Any hints that can be provided here?
>

The files generated by compileAttributes provide the bindings to R for the
exported functions. They are designed to sit alongside your other source
files and you don't ever modify these files directly (they are regenerated
as necessary by compileAttributes).

The core notion is that by placing the Rcpp::export attribute before a
function you've done everything you need to do and we'll take care of the
rest. This entails:

(1) Generating an Rcpp module declaration that includes all exported
functions; and
(2) Calling loadModule with the right list of functions in the
RcppExports.R file

The optional <PackageName.h> file is a bit more complicated because it
interacts with R_GetCCallable. It too is generated so not something you
hand maintain. We are working on a mechanism to mix generated and user code
in inst/include and hope to have that ready for the next release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20121115/dd075802/attachment.html>


More information about the Rcpp-devel mailing list