Abstract
This document attempts to answer the most Frequently Asked Questions (FAQ) regarding the package.
If you have installed, please execute the following command in to access the introductory vignette (which is a variant of the and papers) for a detailed introduction, ideally followed by at least the Rcpp Attributes vignette:
If you do not have installed, these documents should also be available wherever you found this document, on every mirror site of CRAN.
Obviously, must be installed. provides a API as an extension to the system. As such, it is bound by the choices made by and is also influenced by how is configured.
In general, the standard environment for building a CRAN package from source (particularly when it contains or code) is required. This means one needs:
--enable-shared-lib option;make etc.Also see the RStudio documentation on pre-requisites for R package development.
On almost all platforms, the GNU Compiler Collection (or
gcc, which is also the name of its language compiler) can
be used along with the corresponding g++ compiler for the
language. Depending on which C++ compilation standard one wishes to use,
a suitably recent variant of the compiler may be needed. But these days
the minimum standard of C++11 is generally available, and the default
compilers on all the common platforms are now suitable.
Specific per-platform notes:
The clang and clang++ compilers from the
LLVM project can also be used. On Linux, they are inter-operable with
gcc et al. On macOS, they are unfortunately not ABI
compatible.
In general, any compiler supported by R itself can be used.
Additional packages that we have found useful are if one wants to create compiled functions without the help of as well as the different benchmarking and unit testing packages. A short list follows, it is not meant to be exhaustive as CRAN by now has helpful packages:
The package is licensed under the terms of the GNU GPL 2 or later, just like itself. A key goal of the package is to make extending more seamless. But by your code against (as well as ), the combination is bound by the GPL as well. This is very clearly stated at the FSF website:
Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
So you are free to license your work under whichever terms you find suitable (provided they are GPL-compatible, see the FSF site for details). However, the combined work will remain under the terms and conditions of the GNU General Public License. This restriction comes from both which is GPL-licensed as well as from and whichever other GPL-licensed components you may be linking against.
has been specifically designed to be used by other packages. Making a package that uses depends on the same mechanics that are involved in making any package that use compiled code — so reading the manual is a required first step.
Further steps, specific to , are described in a separate vignette.
vignette("Rcpp-package")There are two toolchains which can help with this:
The next two subsections show an example each.
The package provides the functions and . Below is a simple function
that uses accumulate from the () Standard Template Library
to sum the elements of a numeric vector.
fx <- cxxfunction(signature(x = "numeric"),
'NumericVector xx(x);
return wrap(std::accumulate(xx.begin(),
xx.end(), 0.0));',
plugin = "Rcpp")
res <- fx(seq(1, 10, by=0.5))
res## [1] 104.5
One might want to use code that lives in a file instead of writing the code in a character string in R. This is easily achieved by using :
The verbose argument of is very useful as it shows how
runs the show.
Rcpp Attributes , and also discussed in below, permits an even easier
route to integrating R and C++. It provides three key functions. First,
provide a means to evaluate simple C++ expression which is often useful
for small tests, or to simply check if the toolchain is set up
correctly. Second, can be used to create C++ functions for R use on the
fly. Third, Rcpp::sourceCpp can integrate entire files in
order to define multiple functions.
The example above can now be rewritten as:
cppFunction('double accu(NumericVector x) {
return(std::accumulate(x.begin(), x.end(), 0.0));
}')
res <- accu(seq(1, 10, by=0.5))
res## [1] 104.5
The parses the supplied text, extracts the desired function names, creates the required scaffolding, compiles, links and loads the supplied code and makes it available under the selected identifier.
Similarly, can read in a file and compile, link and load the code therein.
Since release 0.3.5 of , one can combine and . See
help("package.skeleton-methods") once is loaded and use the
skeleton-generating functionality to transform a prototype function into
the minimal structure of a package. After that you can proceed with
working on the package in the spirit of .
Rcpp Attributes also offers a means to convert functions written using Rcpp Attributes into a function via the function; see the vignette for details.
The simplest way may be to work directly with a package. Changes to both the and code can be compiled and tested from the command line via:
This first installs the packages, and then uses the command-line tool
(which ships with R) to load the package, and execute the
expression following the -e switch. Such an expression can
contain multiple statements separated by semicolons. is available on all
three core operating systems.
On Linux, one can also use r from the
littler package which is an alternative front end to
designed for both #! (hashbang) scripting and command-line
use. It has slightly faster start-up times than ; and both give a
guaranteed clean slate as a new session is created.
The example then becomes
The -l option calls ‘suppressMessages(library(mypkg))’
before executing the expression. Several packages can be listed,
separated by a comma.
More choices are provided by other packages and IDEs. See their respective documentation for details.
The recommended way is to create a package and follow . The alternate recommendation is to use and follow because it takes care of all the details.
However, some people have shown that they prefer not to follow
recommended guidelines and compile their code using the traditional
R CMD SHLIB. To do so, we need to help SHLIB
and let it know about the header files that provides and the library the
code must link against.
On the Linux command-line, you can do the following:
which first defines and exports two relevant environment variables
which R CMD SHLIB then relies on. On other operating
systems, appropriate settings may have to be used to define the
environment variables.
This approach corresponds to the very earliest ways of building programs and can still be found in some deprecated documents (as e.g. some of Dirk’s older ‘Intro to HPC with R’ tutorial slides). It is still not recommended as there are tools and automation mechanisms that can do the work for you.
Note that we always need to set PKG_CXXFLAGS (or equally
PKG_CPPFLAGS) to tell R where the headers files are
located.
Once R CMD SHLIB has created the dynamically-loadable
file (with extension .so on Linux, .dylib on
macOS or .dll on Windows), it can be loaded in an R session
via , and the function can be executed via . Needless to say, we
recommend using a package, or at least Rcpp Attributes as either
approach takes care of a lot of these tedious and error-prone manual
steps.
We have had reports in the past where build failures occurred when
users had non-standard code in their ~/.Rprofile or
Rprofile.site (or equivalent) files.
If such code emits text on stdout, the frequent and
implicit invocation of Rscript -e "..." (as in above) to
retrieve settings directly from will fail.
You may need to uncomment such non-standard code, or protect it by
wrapping it inside if (interactive()), or possibly try to
use Rscript --vanilla instead of plain
Rscript.
LinkingTo
has only limited support for cross-package linkage.
We now employ the LinkingTo field of the
DESCRIPTION file of packages using . But this only helps in
having compute the location of the header files for us.
The actual library location and argument still needs to be provided by the user. This topic can get complicated real quickly, and there is an entire vignette devoted to it, so see .
Also note that an important change arrived with release 0.11.0 and concerns the automatic registration of functions; see Section below.
Not a chance.
And that is not because we are meanies but because and Visual Studio simply do not get along. As is all about extending with interfaces, we are bound by the available toolchain. And simply does not compile with Visual Studio. Go complain to its vendor if you are still upset.
(These days the ‘Code’ editor derived from it is popular and can of course be used with and ; see its documentation for the required plugins. Such use still falls back to the default compilers is used with on the given system so see above.)
There are three known issues regarding Rcpp build problems on macOS. If you are building packages with RcppArmadillo, there is yet another issue that is addressed separately in below.
By default, macOS does not ship with an active compiler. Depending on the version being used, there are different development environment setup procedures. For the current version, we recommend observing the official procedure used in Section 6.3.2 macOS and Section C.3 macOS of the R Installation and Administration manual.
There are three (or more) distinct versions of R for macOS. The first version is a legacy version meant for macOS 10.6 (Snow Leopard) - 10.8 (Mountain Lion). The second version is for more recent system macOS 10.9 (Mavericks) and 10.10 (Yosemite). Finally, the third and most up-to-date version supports macOS 10.11 (El Capitan), 10.12 (Sierra), and 10.13 (High Sierra). The distinction comes as a result of a change in the compilers shipped with the operating system as highlighted previously. As a result, avoid sending to collaborators if they are working on older operating systems as the binaries for these versions will not be able to mix. In such cases, it is better to provide collaborators with the and allow them to build the package locally.
By default, the macOS operating environment lacks the ability to parallelize sections of code using the standard. Within 3.4.*, the default developer environment was changed to allow for to be used on macOS by using a non-default toolchain provided by R Core Team maintainers for macOS. Having said this, it is still important to protect any reference to as some users may not yet have the ability to use .
To setup the appropriate protection for using , the process is two-fold. First, protect the inclusion of headers with:
Second, when parallelizing portions of code use:
#ifdef _OPENMP
// multithreaded OpenMP version of code
#else
// single-threaded version of code
#endifUnder this approach, the code will be safely parallelized when support exists for on Windows, macOS, and Linux.
Below are additional resources that provide information regarding compiling Rcpp code on macOS.
r-sig-mac list, which is generally recommended for
macOS-specific questions and further consultation.If you are running into trouble compiling code with , please also see listed below.
Yes, it generally does. But as we do not have access to such systems, some issues persist on the CRAN test systems. And now that more time has passed since the question was written, CRAN no longer tests on these platforms.
We have not tested it yet. might need a few tweaks to work with the compilers used by Revolution R (if those differ from the defaults). By now REvolution R is defunct too.
Rho, previously known as CXXR, is an ambitious project that aims to totally refactor the interpreter in . There are a few similarities with but the projects are unrelated.
Rho / CXXR and both want to make more use of but they do it in very different ways. By now, Rho is long defunct too.
version 0.10.0 and later offer a new feature ‘Rcpp Attributes’ which is described in detail in its own vignette . In short, it offers functions , and which extend the functionality of the function.
Starting with 0.11.0, functionality provided by and used by packages
built with accessed via the registration facility offered by R (and
which is used by and , as well as by and ). This requires no effort from
the user / programmer, and even frees us from explicit linking
instruction. In most cases, the files src/Makevars and
src/Makevars.win can now be removed. Exceptions are the use
of (which needs an entry
PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)) and packages
linking to external libraries they use.
But for most packages using , only two things are required:
DESCRIPTION such as
Imports: Rcpp (which may be versioned as in
Imports: Rcpp (>= 0.11.0)), andNAMESPACE to ensure is correctly
instantiated, for example importFrom(Rcpp, evalCpp).The name of the symbol does not really matter; once one symbol is imported all symbols should be available.
Odds are your build failures are due to the absence of
gfortran and its associated libraries. The errors that you
may receive are related to either -lgfortran or
-lquadmath.
To rectify the root of these errors, there are two options available.
The first option is to download and use a fixed set of
gfortran binaries that are used to compile R for macOS
(e.g. given by the maintainers of the macOS build). The second option is
to either use pre-existing gfortran binaries on your
machine or download the latest. These options are described in-depth in
Section
C.3 macOS of the R
Installation and Administration manual. Please consult this manual
for up-to-date information regarding gfortran binaries on
macOS. We have also documented other common macOS compile
issues in Section .
The following questions were asked on the Rcpp-devel mailing list, which is our preferred place to ask questions as it guarantees exposure to a number of advanced Rcpp users. The StackOverflow tag for rcpp is an alternative; that site is also easily searchable.
Several dozen fully documented examples are provided at the Rcpp Gallery – which is also open for new contributions.
I’m curious whether one can provide a class definition inline in an R script and then initialize an instance of the class and call a method on the class, all inline in R.
This question was initially about using templates with , and we show that (older) answer first. It is also easy with Rcpp Attributes which is what we show below.
Most certainly, consider this simple example of a templated class which squares its argument:
inc <- 'template <typename T>
class square :
public std::function<T(T)> {
public:
T operator()( T t) const {
return t*t;
}
};
'
src <- '
double x = Rcpp::as<double>(xs);
int i = Rcpp::as<int>(is);
square<double> sqdbl;
square<int> sqint;
return Rcpp::DataFrame::create(
Rcpp::Named("x", sqdbl(x)),
Rcpp::Named("i", sqint(i)));
'
fun <- cxxfunction(signature(xs="numeric",
is="integer"),
body=src, include=inc,
plugin="Rcpp")
fun(2.2, 3L)## x i
## 1 4.84 9
We can also use ‘Rcpp Attributes’ —as described in and above. Simply place the following code into a file and use on it. It will even run the R part at the end.
#include <Rcpp.h>
template <typename T> class square :
public std::function<T(T)> {
public:
T operator()( T t) const {
return t*t ;
}
};
// [[Rcpp::export]]
Rcpp::DataFrame fun(double x, int i) {
square<double> sqdbl;
square<int> sqint;
return Rcpp::DataFrame::create(
Rcpp::Named("x", sqdbl(x)),
Rcpp::Named("i", sqint(i)));
}
/*** R
fun(2.2, 3L)
*/allows element-wise operations on vector and matrices through operator overloading and STL interface, but what if I want to multiply a matrix by a vector, etc …
Currently, does not provide binary operators to allow operations involving entire objects. Adding operators to would be a major project (if done right) involving advanced techniques such as expression templates. We currently do not plan to go in this direction, but we would welcome external help. Please send us a design document.
However, we have developed the package that provides a bridge between and . supports binary operators on its types in a way that takes full advantage of expression templates to remove temporaries and allow chaining of operations. That is a mouthful of words meaning that it makes the code go faster by using fiendishly clever ways available via the so-called template meta programming, an advanced technique. Also, the package provides an alternative using the Eigen template library.
The following example is adapted from the examples available at the project page of Armadillo. It calculates
lines = '// copy the data to armadillo structures
arma::colvec x = Rcpp::as<arma::colvec> (x_);
arma::mat Y = Rcpp::as<arma::mat>(Y_) ;
arma::colvec z = Rcpp::as<arma::colvec>(z_) ;
// calculate the result
double result = arma::as_scalar(
arma::trans(x) * arma::inv(Y) * z);
// return it to R
return Rcpp::wrap(result);'
writeLines(a, file = "myfile.cpp")If stored in a file myfile.cpp, we can use it via :
fx <- cxxfunction(signature(x_="numeric",
Y_="matrix",
z_="numeric" ),
paste(readLines("myfile.cpp"),
collapse="\n"),
plugin="RcppArmadillo" )
fx(1:4, diag(4), 1:4)The focus is on the code
arma::trans(x) * arma::inv(Y) * z, which performs the same
operation as the R code t(x) %*% solve(Y) %*% z, although
Armadillo turns it into only one operation, which makes it quite fast.
Armadillo benchmarks against other matrix algebra libraries are provided
on the Armadillo
website.
It should be noted that code below depends on the version
0.3.5 of and the version 0.2.2 of .
We can also write the same example for use with Rcpp Attributes:
#include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
// [[Rcpp::export]]
double fx(arma::colvec x, arma::mat Y,
arma::colvec z) {
// calculate the result
double result = arma::as_scalar(
arma::trans(x) * arma::inv(Y) * z
);
return result;
}
/*** R
fx(1:4, diag(4), 1:4)
*/Here, the additional Rcpp::depends(RcppArmadillo)
ensures that code can be compiled against the header, and that the
correct libraries are linked to the function built from the supplied
code example.
Note how we do not have to concern ourselves with conversion; R object automatically become (Rcpp)Armadillo objects and we can focus on the single computing a (scalar) result.
Can I call functions defined in the Rmath header file and the standalone math library for R–as for example the random number generators?
Yes, of course. This math library exports a subset of R, but has
access to much more. Here is another simple example. Note how we have to
use and instance of the RNGScope class to set and re-set
the random-number generator. This also illustrates Rcpp sugar as we are
using a vectorised call to rnorm. Moreover, because the RNG
is reset, the two calls result in the same random draws. If we wanted to
control the draws, we could explicitly set the seed after the
RNGScope object has been instantiated.
fx <- cxxfunction(signature(),
'RNGScope();
return rnorm(5, 0, 100);',
plugin="Rcpp")
set.seed(42)
fx()## [1] 137.096 -56.470 36.313 63.286 40.427
fx()## [1] 137.096 -56.470 36.313 63.286 40.427
Newer versions of Rcpp also provide the actual Rmath function in the
R namespace, as R::rnorm(m,s) to obtain a
scalar random variable distributed as
.
Using Rcpp Attributes, this can be as simple as
cppFunction('Rcpp::NumericVector ff(int n) {
return rnorm(n, 0, 100); }')
set.seed(42)
ff(5)## [1] 137.096 -56.470 36.313 63.286 40.427
ff(5)## [1] -10.6125 151.1522 -9.4659 201.8424 -6.2714
## [1] 137.096 -56.470 36.313 63.286 40.427
rnorm(5, 0, 100)## [1] -10.6125 151.1522 -9.4659 201.8424 -6.2714
This illustrates the Rcpp Attributes adds the required
RNGScope object for us. It also shows how setting the seed
from R affects draws done via C++ as well as R, and that identical
random number draws are obtained.
NA and Inf with
R knows about
NAandInf. How do I use them from C++?
Yes, see the following example:
src <- 'Rcpp::NumericVector v(4);
v[0] = R_NegInf; // -Inf
v[1] = NA_REAL; // NA
v[2] = R_PosInf; // Inf
v[3] = 42; // c.f. Hitchhiker Guide
return Rcpp::wrap(v);'
fun <- cxxfunction(signature(), src, plugin="Rcpp")
fun()## [1] -Inf NA Inf 42
Similarly, for Rcpp Attributes:
Can I multiply matrices easily?
Yes, via the package which builds upon and the wonderful Armadillo library described above in :
txt <- 'arma::mat Am = Rcpp::as< arma::mat >(A);
arma::mat Bm = Rcpp::as< arma::mat >(B);
return Rcpp::wrap( Am * Bm );'
mmult <- cxxfunction(signature(A="numeric",
B="numeric"),
body=txt,
plugin="RcppArmadillo")
A <- matrix(1:9, 3, 3)
B <- matrix(9:1, 3, 3)
C <- mmult(A, B)
CArmadillo supports a full range of common linear algebra operations.
The package provides an alternative using the Eigen template library.
Rcpp Attributes, once again, makes this even easier:
#include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
// [[Rcpp::export]]
arma::mat mult(arma::mat A, arma::mat B) {
return A*B;
}
/*** R
A <- matrix(1:9, 3, 3)
B <- matrix(9:1, 3, 3)
mult(A,B)
*/which can be built, and run, from R via a simple call—and will also run the small R example at the end.
How can I create my own plugin for use by the package?
Here is an example which shows how to it using GSL libraries as an example. This is merely for demonstration, it is also not perfectly general as we do not detect locations first—but it serves as an example:
# simple example of seeding RNG and
# drawing one random number
gslrng <- '
int seed = Rcpp::as<int>(par) ;
gsl_rng_env_setup();
gsl_rng *r = gsl_rng_alloc (gsl_rng_default);
gsl_rng_set (r, (unsigned long) seed);
double v = gsl_rng_get (r);
gsl_rng_free(r);
return Rcpp::wrap(v);'
plug <- Rcpp::Rcpp.plugin.maker(
include.before = "#include <gsl/gsl_rng.h>",
libs = paste(
"-L/usr/local/lib/R/site-library/Rcpp/lib -lRcpp",
"-Wl,-rpath,/usr/local/lib/R/site-library/Rcpp/lib",
"-L/usr/lib -lgsl -lgslcblas -lm")
)
registerPlugin("gslDemo", plug )
fun <- cxxfunction(signature(par="numeric"),
gslrng, plugin="gslDemo")
fun(0)Here the function Rcpp.plugin.maker is used to create a
plugin ‘plug’ which is then registered, and subsequently used by .
The same plugins can be used by Rcpp Attributes as well.
How can I pass another flag to the
g++compiler without writing a new plugin?
The quickest way is to modify the return value from an existing
plugin. Here we use the default one from itself in order to pass the
flag -std=c++11. As it does not set the
PKG_CXXFLAGS variable, we simply assign this. For other
plugins, one may need to append to the existing values instead. An older
example follow (but note that C++11 or newer is the default now with
more recent R releases)
myplugin <- getPlugin("Rcpp")
myplugin$env$PKG_CXXFLAGS <- "-std=c++11"
f <- cxxfunction(signature(),
settings = myplugin, body = '
std::vector<double> x = { 1.0, 2.0, 3.0 };
return Rcpp::wrap(x);
')
f()For Rcpp Attributes, the attributes Rcpp::plugin() can
be used. Currently supported plugins are for C++11 (which is now a
standard for compilation with R, but used to be an opt-in), other
compilation standards C++14, C++17, C++20, C++23, as well as for
OpenMP.
Ok, I can create a matrix, but how do I set its row and columns names?
Pretty much the same way as in itself: We define a list with two
character vectors, one each for row and column names, and assign this to
the dimnames attribute:
src <- '
Rcpp::NumericMatrix x(2,2);
x.fill(42); // or another value
Rcpp::List dimnms = // list with 2 vecs
Rcpp::List::create( // with static names
Rcpp::CharacterVector::create("cc", "dd"),
Rcpp::CharacterVector::create("ee", "ff")
);
// and assign it
x.attr("dimnames") = dimnms;
return(x);
'
fun <- cxxfunction(signature(),
body=src, plugin="Rcpp")
fun()The same logic, but used with Rcpp Attributes:
#include <Rcpp.h>
// [[Rcpp::export]]
Rcpp::List fun(void) {
Rcpp::NumericMatrix x(2,2);
x.fill(42); // or another value
Rcpp::List dimnms = // list with 2 vecs
Rcpp::List::create( // with static names
Rcpp::CharacterVector::create("cc", "dd"),
Rcpp::CharacterVector::create("ee", "ff"));
// and assign it
x.attr("dimnames") = dimnms;
return(x);
}That is a good and open question. We rely on the basic types, notably
integer and numeric. These can be cast to and
from types without problems. But there are corner cases. The following
example, contributed by a user, shows that we cannot reliably cast
long types (on a 64-bit machines).
BigInts <- cxxfunction(signature(),
'std::vector<long> bigints;
bigints.push_back(12345678901234567LL);
bigints.push_back(12345678901234568LL);
Rprintf("Difference of %ld\\n",
12345678901234568LL - 12345678901234567LL);
return wrap(bigints);',
plugin="Rcpp", includes="#include <vector>")
retval <- BigInts()
# Unique 64-bit integers were cast to identical
# lower precision numerics behind my back with
# no warnings or errors whatsoever. Error.
stopifnot(length(unique(retval)) == 2)While the difference of one is evident at the level, it is no longer
present once cast to . The 64-bit integer values get cast to a floating
point types with a 53-bit mantissa. We do not have a good suggestion or
fix for casting 64-bit integer values: 32-bit integer values fit into
integer types, up to 53 bit precision fits into
numeric and beyond that truly large integers may have to
converted (rather crudely) to text and re-parsed. Using a different
representation as for example from the GNU
Multiple Precision Arithmetic Library may be an alternative.
However, with care, and via the package , can use
integer64 as a type (but storing the 64 bits in a
double), and can help with conversion back and forth.
I would like to typeset the vignettes. What do I need?
The TeXLive distribution seems to get bigger and bigger. What you need to install may depend on your operating system.
Specific per-platform notes:
texlive-base, texlive-latex-base, texlive-generic-recommended, texlive-fonts-recommended, texlive-fonts-extra, texlive-extra-utils, texlive-latex-recommended, texlive-latex-extra.
Using texlive-full may be a shortcut. Fedora and other
distributions should have similar packages.Ok, I would like to pass object but you only allow 20. How come?
In essence, and in order to be able to compile it with the largest number of compilers, is constrained by the older C++ standards which do not support variadic function arguments. So we actually use macros and code generator scripts to explicitly enumerate arguments, and that number has to stop at some limit. We chose 20.
A good discussion is available at this StackOverflow
question concerning data.frame creation with . One solution offers a
custom ListBuilder class to circumvent the limit; another
suggests to simply nest lists.
Yes, you can use default parameters with some limitations. The limitations are mainly related to string literals and empty vectors. This is what is currently supported:
"foo")10 or
4.5)true and false
R_NilValue, NA_STRING,
NA_INTEGER, NA_REAL, and
NA_LOGICAL.::create static member function.
CharacterVector, IntegerVector, and
NumericVector
Rcpp::<Type>Matrix n(rows,cols)
CharacterMatrix, IntegerMatrix, and
NumericMatrix
To illustrate, please consider the following example that provides a short how-to:
#include <Rcpp.h>
// [[Rcpp::export]]
void sample_defaults(
NumericVector x =
NumericVector::create(), // Size 0 vector
bool bias = true, // Set to true
std::string method =
"rcpp rules!") { // Set string
Rcpp::Rcout << "x size: " << x.size() << ", ";
Rcpp::Rcout << "bias value: " << bias << ", ";
Rcpp::Rcout << "method value: " << ".";
}
/*** R
sample_defaults() # all defaults
sample_defaults(1:5) # supply x values
sample_defaults(bias = FALSE, # supply bool
method = "Rlang") # and string
*/Note: In cpp, the default bool values are
true and false whereas in R the valid types
are TRUE or FALSE.
But of course. In a nutshell, this boils down to , and also . We expanded a little on this in Rcpp Gallery article providing more detail. What follows in an abridged summary.
You can always set appropriate PKG_CXXFLAGS as an
environment variable, or via ~/.R/Makevars. You can also
set plugins and/or R support from src/Makevars:
sourceCpp() etc. For packages, R has supported it since R
3.1.0 which added the option to select the language standard via
CXX_STD = CXX11. As of early 2017, over 120 packages on
CRAN use this. As of R 4.0.0, this is the minimum standard and no longer
needed.sourceCpp() etc. For packages, R supports it since R 3.4.0
adding the option to select the language standard via
CXX_STD = CXX14. It became the default with R 4.1.0.sourceCpp(), or via PKG_CXXFLAGS or other
means to set compiler options. It became the default with R 4.3.0, but
compiler support may not be widespread.In a comment to issue ticket #770 it is stated that running
helps within this environment as it installs the corresponding
x86_64-conda_cos6-linux-gnu-c++ compiler. Documentation for
this and other systems is provided at
this page.
Somewhat. One option is to cache as much as possible via ccache by adding it to
~/.R/Makevars.
Depending on what parts of Rcpp are being used, compilation speed can
be increased by turning use of Modules off. Starting with version 1.0.3,
the RCPP_NO_MODULES define can be used. It can be set in
src/Makevars as an argument to PKG_CXXFLAGS
(or one of the other C++ dialect options) as
-DRCPP_NO_MODULES. This has the advantage of affecting
all files in the package, including the auto-generated
RcppExports.cpp where it might be trickier to set it
manually.
Beyond modules, RTTI support can also be turned off. this implies
turning Modules support off as well so. To select this approach, use the
RCPP_NO_RTTI define.
Starting with version 1.0.8 of , new headers , , make this much easier as they exclude these different (layered) bits of functionality.
You bet. We use to generate html, latex and man page documentation from the source. The html documentation is available for browsing, as a very large pdf file, and all three formats are also available a zip-archives: html, latex, and man.
We take quality seriously and have developed an extensive unit test suite to cover many possible uses of the API.
We are always on the look for more coverage in our testing. Please let us know if something has not been tested enough.
The Rcpp-devel mailing list hosted at R-forge is by far the best place. You may also want to look at the list archives to see if your question has been asked before.
You can also use StackOverflow via its ‘rcpp’ tag.
The normal Rcpp-devel mailing list hosting at R-forge contains an archive, which can be searched via swish.
Alternatively, one can also use Mail-Archive on Rcpp-devel which offers web-based interfaces, including searching.
We maintain a list of open issues in the Github repository. We welcome pull requests and suggest that code submissions come corresponding unit tests and, if applicable, documentation.
If you are willing to donate time and have skills in C++, let us know. If you are willing to donate money to sponsor improvements, let us know too.
You can also spread the word about . There are many packages on CRAN that use , yet are not using . You could blog about it, or get the word out otherwise.
Last but not least the Rcpp Gallery is open for user contributions.
It is very generous of you to still want to help. Perhaps you can tell us what it is that you dislike. We are very open to criticism.
Sure you can. Just send us an email, and we will be happy to discuss the request.
From late 2008 to late 2013, we used the Subversion repository at R-Forge which contained and a number of related packages. It still has the full history as well as number of support files.
We have since switched to a Git repository at Github for (as well as for and ).
Contained within this section is a list of known issues regarding . The issues listed here are either not able to be fixed due to breaking application binary interface (ABI), would impact the ability to reproduce pre-existing results, or require significant work. Generally speaking, these issues come to light only when pushing the edge capabilities of .
objects are wrappers around the underlying objects’
SEXP, or S-expression. The SEXP is a pointer
variable that holds the location of where the object data has been
stored . That is to say, the SEXP does not hold
the actual data of the object but merely a reference to where the data
resides. When creating a new object for an object to enter , this object
will use the same SEXP that powers the original object if
the types match otherwise a new SEXP must be created to be
type safe. In essence, the underlying SEXP objects are
passed by reference without explicit copies being made into . We refer
to this arrangement as a proxy model.
As for the actual implementation, there are a few consequences of the proxy model. The foremost consequence within this paradigm is that pass by value is really a pass by reference. In essence, the distinction between the following two functions is only visual sugar:
In particular, when one is passing by value what occurs is the
instantiation of the new object that uses the same SEXP for
the object. As a result, the object is ``linked’’ to the original
object. Thus, if an operation is performed on the object, such as adding
1 to each element, the operation also updates the object causing the
change to be propagated to ’s interactive environment.
#include<Rcpp.h>
// [[Rcpp::export]]
void implicit_ref(Rcpp::NumericVector X) {
X = X + 1.0;
}
// [[Rcpp::export]]
void explicit_ref(Rcpp::NumericVector& X) {
X = X + 1.0;
}R use
a <- 1.5:4.5
b <- 1.5:4.5
implicit_ref(a)
a## [1] 2.5 3.5 4.5 5.5
explicit_ref(b)
b## [1] 2.5 3.5 4.5 5.5
There are two exceptions to this rule. The first exception is that a
deep copy of the object can be made by explicit use of
Rcpp:clone(). In this case, the cloned object has no link
to the original object. However, there is a time cost associated with
this procedure as new memory must be allocated and the previous values
must be copied over. The second exception, which was previously
foreshadowed, is encountered when and object types do not match. One
frequent example of this case is when the object generated from
seq() or a:b reports a class of
"integer" while the object is setup to receive the class of
"numeric" as its object is set to
NumericVector or NumericMatrix. In such cases,
this would lead to a new SEXP object being created behind
the scenes and, thus, there would not be a link between the
object and object. So, any changes in would not be propagated to unless
otherwise specified.
#include<Rcpp.h>
// [[Rcpp::export]]
void int_vec_type(Rcpp::IntegerVector X) {
X = X + 1.0;
}
// [[Rcpp::export]]
void num_vec_type(Rcpp::NumericVector X) {
X = X + 1.0;
}R use:
a <- 1:5
b <- 1:5
class(a)## [1] "integer"
int_vec_type(a)
a # variable a changed as a side effect## [1] 2 3 4 5 6
num_vec_type(b)
b # b unchanged as copy was made for numeric## [1] 1 2 3 4 5
With this being said, there is one last area of contention with the
proxy model: the keyword const. The const
declaration indicates that an object is not allowed to be modified by
any action. Due to the way the proxy model paradigm works, there is a
way to “override” the const designation. Simply put, one
can create a new object without the const declaration from
a pre-existing one. As a result, the new object would be allowed to be
modified by the compiler and, thus, modifying the initial
SEXP object. Therefore, the initially secure object would
be altered. To illustrate this phenomenon, consider the following
scenario:
#include <Rcpp.h>
// [[Rcpp::export]]
Rcpp::IntegerVector const_override_ex(
const Rcpp::IntegerVector& X) {
Rcpp::IntegerVector Y(X); // Create object
// from SEXP
Y = Y * 2; // Modify new object
return Y; // Return new object
}R use:
x <- 1:10 # an integer sequence
# returning an altered value
const_override_ex(x)## [1] 2 4 6 8 10 12 14 16 18 20
# but the original value is altered too!
x## [1] 2 4 6 8 10 12 14 16 18 20
So we see that with SEXP objects, the const
declaration can be circumvented as it is really a pointer to the
underlying R object.
Not all expressions are directly compatible with
operator=. Compatibility issues stem from many objects and
functions returning an intermediary result which requires an explicit
conversion. In such cases, the user may need to assist the compiler with
the conversion.
There are two ways to assist with the conversion. The first is to
construct storage variable for a result, calculate the result, and then
store a value into it. This is typically what is needed when working
with Character<Type> and String in due
to the Rcpp::internal::string_proxy class. Within the
following code snippet, the aforementioned approach is emphasized:
#include<Rcpp.h>
// [[Rcpp::export]]
std::string explicit_string_conv(
Rcpp::CharacterVector X) {
std::string s; // define storage
s = X[0]; // assign from CharacterVector
return s;
}If one were to use a direct allocation and assignment strategy,
e.g. std::string s = X[0], this would result in the
compiler triggering a conversion error on some platforms. The
error would be similar to:
error: no viable conversion from 'Proxy'
(aka 'string_proxy<16>') to 'std::string'
(aka 'basic_string<char, char_traits<char>,
allocator<char> >')The second way to help the compiler is to use an explicit type
conversion function, if one were to exist. Examples of type conversion
functions include as<T>(), .get() for
cumsum(), is_true() and
is_false() for any() or
all().
operator= with a scalar replaced the object
instead of filling element-wise
Assignment using the operator= with either
Vector and Matrix classes will not elicit an
element-wise fill. If you seek an element-wise fill, then use the
.fill() member method to propagate a single value
throughout the object. With this being said, the behavior of
operator= differs for the Vector and
Matrix classes.
The implementation of the operator= for the
Vector class will replace the existing vector with the
assigned value. This behavior is valid even if the assigned value is a
scalar value such as 3.14 or 25 as the object is cast into the
appropriate object type. Therefore, if a Vector is
initialized to have a length of 10 and a scalar is assigned via
operator=, then the resulting Vector would
have a length of 1. See the following code snippet for the
aforementioned behavior.
#include<Rcpp.h>
// [[Rcpp::export]]
void vec_scalar_assign(int n, double fill_val) {
Rcpp::NumericVector X(n);
Rcpp::Rcout << "Value of Vector " <<
"on Creation: " <<
std::endl << X << std::endl;
X = fill_val;
Rcpp::Rcout << "Value of Vector " <<
"after Assignment: " <<
std::endl << X << std::endl;
}R use:
vec_scalar_assign(5L, 3.14)## Value of Vector on Creation:
## 0 0 0 0 0
## Value of Vector after Assignment:
## 3.14
Now, the Matrix class does not define its own
operator= but instead uses the Vector class
implementation. This leads to unexpected results while attempting to use
the assignment operator with a scalar. In particular, the scalar will be
coerced into a square Matrix and then assigned. For an
example of this behavior, consider the following code:
#include<Rcpp.h>
// [[Rcpp::export]]
void mat_scalar_assign(int n, double fill_val) {
Rcpp::NumericMatrix X(n, n);
Rcpp::Rcout << "Value of Matrix " <<
"on Creation: " <<
std::endl << X << std::endl;
X = fill_val;
Rcpp::Rcout << "Value of Matrix " <<
"after Assignment: " <<
std::endl << X << std::endl;
}R use:
mat_scalar_assign(2L, 3.0)## Value of Matrix on Creation:
## 0.00000 0.00000
## 0.00000 0.00000
##
## Value of Matrix after Assignment:
## 0.00000 0.00000 0.00000
## 0.00000 0.00000 0.00000
## 0.00000 0.00000 0.00000
Prior to ’s 3.0.0, the largest vector one could obtain was at most elements. With the release of ’s 3.0.0, long vector support was added to allow for largest vector possible to increase up to elements on x64 bit operating systems (c.f. Long Vectors help entry). Once this was established, support for long vectors within the paradigm was introduced with version 0.12.0 (c.f 0.12.0 annoucement).
However, the requirement for using long vectors in necessitates the
presence of compiler support for the R_xlen_t, which is
platform dependent on how ptrdiff_t is implemented.
Unfortunately, this means that on the Windows platform the definition of
R_xlen_t is of type long instead of
long long when compiling under the specification.
Therefore, to solve this issue one must compile under the specification
for or later version.
There are three options to trigger compilation with . The first – and
most likely option to use – will be the plugin support offered by
attributes. This can be engaged by adding
// [[Rcpp::plugins(cpp11)]] to the top of the script. For
diagnostic and illustrative purposes, consider the following code which
checks to see if R_xlen_t is available on your
platform:
#include <Rcpp.h>
// Force compilation mode to C++11
// [[Rcpp::plugins(cpp11)]]
// [[Rcpp::export]]
bool test_long_vector_support() {
#ifdef RCPP_HAS_LONG_LONG_TYPES
return true;
#else
return false;
#endif
}R use:
test_long_vector_support()## [1] TRUE
The remaining two options are for users who have opted to embed code
within an package. In particular, the second option requires adding
CXX_STD = CXX11 to a Makevars file found in
the /src directory. Finally, the third option is to add
SystemRequirements:C++11 in the package’s
DESCRIPTION file.
Please note that the support for prior to v3.3.0 on Windows is limited. Therefore, plan accordingly if the goal is to support older versions of .
CharacterVector produces
problematic results
The Standard Template Library’s (STL) std::sort
algorithm performs adequately for the majority of data types. The
notable exception that makes what would otherwise be a universal
quantifier into an existential quantifier is the
CharacterVector data type. Chiefly, the issue with sorting
strings is related to how the CharacterVector relies upon
the use of Rcpp::internal::string_proxy. In particular,
Rcpp::internal::string_proxy is not MoveAssignable
since the left hand side of
operator=(const string_proxy \&rhs) is not
viewed as equivalent to the right hand side before the operation . This
further complicates matters when using CharacterVector with
std::swap, std::move, std::copy
and their variants.
To avoid unwarranted pain with sorting, the preferred approach is to
use the .sort() member function of objects. The member
function correctly applies the sorting procedure to objects regardless
of type. Though, sorting is slightly problematic due to locale as
explained in the next entry. In the interim, the following code example
illustrates the preferred approach alongside the problematic STL
approach:
#include <Rcpp.h>
// [[Rcpp::export]]
Rcpp::CharacterVector preferred_sort(
Rcpp::CharacterVector x) {
Rcpp::CharacterVector y = Rcpp::clone(x);
y.sort();
return y;
}
// [[Rcpp::export]]
Rcpp::CharacterVector stl_sort(
Rcpp::CharacterVector x) {
Rcpp::CharacterVector y = Rcpp::clone(x);
std::sort(y.begin(), y.end());
return y;
}R use:
## [1] "C" "f" "B" "a" "e" "E" "D" "d" "c" "A" "b"
preferred_sort(X)## [1] "A" "B" "C" "D" "E" "a" "b" "c" "d" "e" "f"
stl_sort(X)## [1] "f" "f" "f" "f" "f" "f" "f" "f" "f" "C" "f"
In closing, the results of using the STL approach do change depending
on whether libc++ or libstdc++ standard
library is used to compile the code. When debugging, this does make the
issue particularly complex to sort out. Principally, compilation with
libc++ and STL has been shown to yield the correct results.
However, it is not wise to rely upon this library as a majority of code
is compiled against libstdc++ as it more complete.
Comparing strings within hinges on the ability to process the locale
or native-language environment of the string. In , there is a function
called Scollate that performs the comparison on locale.
Unfortunately, this function has not been made publicly available and,
thus, does not have access to it within its implementation of
StrCmp. As a result, strings that are sorted under the
.sort() member function are ordered improperly.
Specifically, if capitalization is present, then capitalized words are
sorted together followed by the sorting of lowercase words instead of a
mixture of capitalized and lowercase words. The issue is illustrated by
the following code example:
#include <Rcpp.h>
// [[Rcpp::export]]
Rcpp::CharacterVector rcpp_sort(
Rcpp::CharacterVector X) {
X.sort();
return X;
}R use:
## [1] "a" "A" "b" "B" "c"
rcpp_sort(x)## [1] "A" "B" "a" "b" "c"
R 3.4.0 and later strongly encourage registering dynamically loadable
symbols. In the stronger form (where .registration=TRUE is
added to the useDynLib() statement in
NAMESPACE), only registered symbols can be loaded. This is
fully supported by Rcpp 0.12.12 and later, and the required code is
added to src/RcppExports.cpp.
However, the transition from the previously generated file
src/RcppExports.cpp to the new one may require running
compileAttributes() twice (which does not happen when,
e.g., devtools is used). When
Rcpp::compileAttributes() is called, it also calls
tools::package_native_routine_registration_skeleton(),
which crawls through usages of .Call() in the
R/ source files of the package to figure out what routines
need to be registered. If an older RcppExports.R file is
discovered, its out-of-date symbol names get picked up, and registration
rules for those symbols get written as well. This will register more
symbols for the package than are actually defined, leading to an error.
This point has been discussed at some length both in the GitHub issue
tickets, on StackOverflow and elsewhere.
So if your autogenerated file fails, and a
symbols not found error is reported by the linker, consider
running compileAttributes() twice. Deleting
R/RcppExports.R and src/RcppExports.cpp may
also work.
Within limits, yes. Code that is generated via Rcpp Attributes (see
and Section~) generally handles this correctly and gracefully via the
try-catch layer it adds shielding the exception from
propagating to another, separate dynamic library.
However, this mechanism relies on dynamic linking with the (system
library) libgcc providing the C++ standard library (as well
as on using the same C++ standard library across all compiled
components). But this library is linked statically on Windows putting a
limitation on the use of stop() from within Rcpp Modules .
Some more background on the linking requirement is in
this SO question.
If you see tests of your package fail with an error ‘… not provided
by Rcpp’, frequently pointing at either dataptr or
enterRNGScope, then the package may not have been
initialized correctly. For your package, it is generally recommended to
have both Imports: Rcpp and LinkingTo: Rcpp in
the file DESCRIPTION combined with an explicit
importFrom("Rcpp", "evalCpp") in the file
NAMESPACE. Doing so ensures that this symbol is registered
when your package is loaded by R, and as a side-effect certain other
function identifiers will also be resolved properly.
R_lsInternal’
In issue #1148 an error
due to overeager includes was reported. Including
Rinternals.h along with the (macOS-only)
mach/boolean.h lead to linker error as
mach/boolean redefines TRUE leading to bad
interactions with the Rboolean enum type. A very simple
solution is to be more careful and conservative with
#include files and a) have
#include <mach/boolean.h> appear first and b) skip
the #include <Rinternals.h> as it is included by
Rcpp.h anyway.
No. Use actual STL vectors instead. This has been stated clearly many times going back to the original announcement in Feb 2010, StackOverflow answers in Dec 2011 and in Dec 2012, the rcpp-devel list in Jun 2013, another StackOverflow answer in Nov 2013, an early Rcpp Gallery post in Dec 2013, again on StackOverflow Dec 2014, as well as in the ‘Advanced R’ first and second editions. For emphasis, here is a quote from the rcpp-devel post:
Those are somehow cosmetic additions. The usual suggestion is not to use push_front and push_back on Rcpp types.
We use R’s memory, and in R, resizing a vector means moving the data. So if you push_back 3 times, you’re moving the data 3 times.
Using R own memory is the best ever decision we made in Rcpp. You can always use your own data structures to accumulate data, perhaps using stl types and then convert back to R types, which is something we make easy to do.
Many code examples and packages show exactly that approach (as e.g. discussed in the Rcpp Gallery post). Anybody who claims otherwise is (possibly intentionally) misleading.
The Date and Datetime classes, and their
vector variants, go back a very long time to the very beginning of and
use in interfacing . Their intent was, essentially, to hold (single)
start and end values delineating an interval. The design is far from
optimal, but the interface is now established. We have rewritten them
once, and do not plan to rewrite them in the near future. Those looking
to parse and convert many dates at once could look at where we
use the Boost parser, or similar approaches using the C++ headers-only
libraries in packages and . We are not likely to carry this over to the
package as there are advantages in remaining dependency-free.