Can I stop it?
That requires to add RcppArmadillo to Imports, when otherwise LinkingTo would be enough.
Does this already trigger Roxygen to do this?
#include "RcppArmadillo.h"
// [[Rcpp::depends(RcppArmadillo)]]
Related
#include <cmath>
#include <math.h>
#include <Rcpp.h>
// [[Rcpp::plugins("cpp17")]]
// [[Rcpp::export]]
double rcpp_hello_world(Rcpp::NumericVector x) {
double z;
z = std::cyl_bessel_i(0, x[0]);
return z ;
}
When I run the above code and call it using sourceCpp, it works as expected. However inside a R package setup I get
error: cyl_bessel_iis not a member of ‘std
11 | z = std::cyl_bessel_i[0]);
| ^~~~~~~~~~~~
make: *** [/usr/lib64/R/etc/Makeconf:177: rcpp_hello_world.o] Error 1
ERROR: compilation failed for package ‘Package’
upon running Rcpp::compileAttributes() and devtools::document(). I initialised the package with Rcpp.package.skeleton.
cyl_bessel_i was added to the standard library in C++17.
I am using gcc-12.1.0-2 and R-4.2.0-3. I am on Arch Linux.
The default C++ standard used in current versions of R is C++11 (or C++14 if available). Since you require C++17, you need to declare it in the src/Makevars file, using the line
CXX_STD=CXX17
In a comment you referred to the Rcpp documentation which says that Makevars is optional since Rcpp 0.11.0. I think that was written about linking to the Rcpp libs, but it is also true here, as pointed out by #MikkoMarttila: you can alternatively declare the C++ version in the SystemRequirements: field of the DESCRIPTION file, e.g.
SystemRequirements: C++17
To use RcppArmadillo, we're often instructed to have the following lines at the top:
#include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
Why do we need both? Isn't the #include directive sufficient for us to have access to all functions defined inside the scope of RcppArmadillo?
There are two different things at play:
The compiler needs the header RcppArmadillo.h in order to know about types from (Rcpp)Armadillo, Rcpp (as this one pulls in Rcpp.h as well) and therefore R. I presume you know you need this. But ...
How would R know to add the -I... flag required for this? It wouldn't!
At a package level the LinkingTo: helps for the header case. But in deeper sense sometimes we need headers and linking (ie RcppGSL) and in that case, the hook we have here via Rcpp::depends into Rcpp Attributes ensures we can do this.
So the // [[Rcpp::depends(RcppArmadillo)]] helps for sourceCpp() use. It is not needed in a package. "Plugins" like this are discussed a little in the Rcpp Attributes vignette.
I submitted my package to the CRAN repository. The package was accepted without errors but in the second step of checking the CRAN maintainers reported the following error.
Unfortunately I don't understand how I can fix it.
In file included from /Builds/CRAN-QA-Simon/packages/mavericks-x86_64/Rlib/3.3/RcppArmadillo/include/armadillo:23:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/fstream:864:20: error:
no member named 'Rf_error' in 'std::__1::codecvt_base'; did you mean simply 'Rf_error'?
if (__r == codecvt_base::error)
^~~~~~~~~~~~~~
/Library/Frameworks/R.framework/Resources/include/R_ext/Error.h:35:12: note:
'Rf_error' declared here
void NORET Rf_error(const char *, ...);
^
In my C++ file, I wrote:
#include <math.h>
#include "ANN/ANN.h"
#include "NN.h"
#include <R.h>
#include "RcppArmadillo.h"
#include <map>
#include <vector>
#include <iostream>
How do I have to correct this? Has Rpp.h to be included?
R itself is written in C, due to its early start way back in the early 1990s. C has no namespaces -- which can lead to conflicts as we lack the namespace separation. Identifiers from different libraries sharing the same name can be mistaken. This has happened here.
R uses, in its C API, functions length(), error(), .... etc which, given how common the name is, are likely to clash. So R has as mechanism of prepending Rf_ to its symbols: error becomes Rf_error. This use the preprecessor, which is reasonably dumb (as opposed to using the compiler itself). So when R sees error it wants it to be Rf_error.
What happens here is that you very likely has #include <RcppArmadillo.h> (and therefore the implicit #include <Rcpp.h> before the include for your actual library. Try it the other way around. That way R's messing with its error() will not interfere with the library one which is confusing you here.
I would like to write a C++ function with Rcpp that uses a C function found in the package hypred, which is on CRAN here.
I read using C function from other package in Rcpp, but don't understand if this applies for me and if it would apply, what to do.
The desired function is in the the source file /src/hypredRoutines.c and is called meiosisFUNAllChr.
What I so far did based on this SO question here is:
I separated the function meiosisFUNAllChr from the rest of the code and placed it in a new file called meiosisFUNAllChr.c.
I created a header file called meiosisFUNAllChr.h containing:
#ifndef MEIOSISFUNALLCHR_H
#define MEIOSISFUNALLCHR_H
void meiosisFUNallChr (...);
#endif
Compiled it with
gcc -c -o meiosisFUNAllChr.o meiosisFUNAllChr.c
Created a dummy c++ function
#include <Rcpp.h>
using namespace Rcpp;
extern "C" {
#include "meiosisFUNallChr.h"
}
// [[Rcpp::export]]
int timesTwo(int x) {
return x * 2;
}
At this point, compiling with sourceCpp does not work. Can you show me how to get it working?
Many Thanks!
EDIT
Compiling with sourceCpp gives me:
meiosisFUNallChr.h: file or directory not found
hypred registers its two functions, at the R level you can get hold of the one you want like this:
xp <- getDLLRegisteredRoutines( getLoadedDLLs()[["hypred"]] )[[".C"]][["meiosisFUNallChr"]]$address
I believe you can then access the function pointer in C++ like this:
DL_FUNC meiosisFUNallChr = reinterpret_cast<DL_FUNC>( R_ExternalPtrAddr(xp) ) ;
But you'd be better off negotiating with the package authors that they implement this scheme if you can make a case that you really need to be calling the C function directly.
Briefly:
You want to use another source file (presumably available under a suitable license).
You want to call it from a new file of yours.
So you already have two files.
By now the alarm bells should go off that you really, really, want to create a package.
Which the Rcpp documentation details in many places. And there are 340+ packages on CRAN using Rcpp, many doing this very issue of calling a C file too. Pick one or two, study their structure; also pick one or two created by the fully documented Rcpp tools such as Rcpp.package.skeleton() and things should become a lot clearer.
Edit: Obviously, this approach only needs to be taken if the other package does not export its function. If you can get its author to export, use that as mention in Romain's answer. Pairs of packages that export/use are zoo/xts, xts/RcppXts, expm/RcppKalman (not on CRAN), RApiSerialize/RcppRedis, ...
I got some code for using OpenGL in Qt. And when I run it I got error as below:
C:\Users\Administrator\Desktop\NeHe6\NeHe6-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\..\NeHe6\nehewidget.cpp:54: error: 'gluLookAt' was not declared in this scope
It seems the header is missing. And the current headers are:
#include "nehewidget.h"
#include <QtGui>
#include <qtopengl\QtOpenGL>
And "nehewidget.h" contains below headers:
#include <qtopengl\QGLWidget>
#include <QTimer>
Could anyone tell me what is the missing header?
It looks like it cant find the libraries you need. Check your installation of the openGL helper libraries. Specifically it is looking for GLU. You need to add it to your linker options, for example -lGLU. You then need to include it your code:
#include <GL/glu.h>
Examples of linking and including GLU (and GLUT) across multiple platforms can be found here
Add this line at the end of the .pro file and you add the lib to your project:
LIBS += -L/usr/local/lib -lGLU