[Rcpp-devel] Rcpp 0.10

terrance savitsky tds151 at gmail.com
Thu Nov 22 03:36:40 CET 2012

Hi,  I've read this note a few times and still find myself similarly
confused.   Does the new compileAttributes() for //[[Rcpp::export]] tagged
functions intend to provide a more streamlined alternative to employment of
RcppExport inclusions in declarations in the header file and subsequent
 use of .Call() to use a package c++ file within the R files that compose
the package?  Presently, I use .Call for exported c++ functions and wrap
them in associated R functions within the R files that compose my package
and write documentation (processed by roxygen2) at the R-layer for the
wrapped C++ function.  The resulting functions are typically used in other
R functions of my package.   Is the more streamlined suggested path to
compose the documentation statements directly to the C++ layer and then
simply load RcppExports.R, using an #' @include RcppExports.R at the R
layer within a package to allow roxygen2 to add to collated files in the
package Description file such that they would then be readily available
within the R files of the package for developer use?  Under the new scheme,
do I no longer need to include RcppExport in my .h file if I appropriately
employ //[[Rcpp::export]]?    All to say, it is unclear to me whether the
intended use of compileAttributes() is solely to help package writers allow
package users to more easily access the c++ functions at the R layer or
additionally to also streamline how package developers source c++ files
within their own package development process under Rcpp.

Thanks, as always, for your work and expertise.

Terrance Savitsky

On Thu, Nov 15, 2012 at 11:18 AM, JJ Allaire <jj.allaire at gmail.com> wrote:

> 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.
> _______________________________________________
> 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

Thank you, Terrance Savitsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20121121/a5ee7974/attachment.html>

More information about the Rcpp-devel mailing list