[Rcpp-devel] namespace problems in adding C++ to an R project that already uses R

[Daniel Kelley]

Short version: are there any docs on namespace difficulties that might be
encountered whilst adding C++ to an R project that already uses C?

Long version (and I really do apologize for the length).

I am trying to convert some of the C in my biggish package ("oce", 70 kloc R
and 7 kloc C) from C to C++, because I think that will be easier for users to
work with, if they run into trouble and cannot contact me quickly.

The package is pretty old, and although I use roxygen for manpages, I wrote
NAMESPACE manually; it has

```
LinkingTo: Rcpp
Imports: Rcpp
```

as I think is required, for using Rcpp.

So far, I'm working with just a single function, named "trap" (for trapeziodal
integration), and it starts as below.

```
#include <Rcpp.h>
using namespace Rcpp;

//' trapezoidal integration
//'
//' This is an interface to C++ code.
//' @param x vector of x values
//' @param y vector of y values
//' @param type number indicating type, 0, 1 or 2
//' @export
// [[Rcpp::export]]
NumericVector trap(NumericVector x, NumericVector y, NumericVector type)
{
```

Building in Rstudio causes src/RcppExports.cpp to be created as below.  *NOTE:
there is no created code relating to CallEntries or R_init_oce, both of which I
see (the latter analogously) being defined when I make an Rcpp skeleton
project, and I think this may be close to the heart of the problem.*

```
// Generated by using Rcpp::compileAttributes() -> do not edit by hand
// Generator token: 10BE3573-1514-4C36-9D1C-5A225CD40393

#include <Rcpp.h>

using namespace Rcpp;

// trap
NumericVector trap(NumericVector x, NumericVector y, NumericVector type);
RcppExport SEXP _oce_trap(SEXP xSEXP, SEXP ySEXP, SEXP typeSEXP) {
BEGIN_RCPP
    Rcpp::RObject rcpp_result_gen;
    Rcpp::RNGScope rcpp_rngScope_gen;
    Rcpp::traits::input_parameter< NumericVector >::type x(xSEXP);
    Rcpp::traits::input_parameter< NumericVector >::type y(ySEXP);
    Rcpp::traits::input_parameter< NumericVector >::type type(typeSEXP);
    rcpp_result_gen = Rcpp::wrap(trap(x, y, type));
    return rcpp_result_gen;
END_RCPP
}
```

With things established as the above, the package builds without error, and I can do

```
.Call("_oce_trap", x, y, type)
```

which works fine. HOWEVER,

```
.Call(`_oce_trap`, x, y, type)
```
(as in the auto-generaged code in R/RcppExports.R) fails with

```
Error: object '_oce_trap' not found
```

Of course, the R code that gets written automatically also fails, because it
uses `oce_trap`.

The thing is, I am happy to use .Call() and the above would not be a problem, but there
is an autogenerated trap() function in R, and it uses the backtick form and therefore
devtools::check() gives a NOTE on the package, which I certainly do not want.

Since I noticed that the autogenerated src/RcppExports.cpp
lacked anything about CallEntries or R_init_oce, I edited my existing
src/registerDynamicSymbol.c file, in which I had registered symbols for my
C code.  That file now looks like the following. Here, the CallEntries definition is new,
as is the extern and also the third argument to R_registerRoutines(), which was 
NULL when I was just using C.

```
#include <R.h>
#include <Rinternals.h>
#include <R_ext/Rdynload.h>

extern SEXP _oce_trap(SEXP, SEXP, SEXP);

static const R_CallMethodDef CallEntries[] = {
    {"_oce_trap", (DL_FUNC) &_oce_trap, 3},
    {NULL, NULL, 0}
};

void R_init_oce(DllInfo* info) {
    R_registerRoutines(info, NULL, CallEntries, NULL, NULL);
    R_useDynamicSymbols(info, TRUE);
}
```

Well, the above is a sketch of what I think are salient details. I am not entirely sure, but
it seems to me that `_oce_trap` ought to accessible with .Call(). But it's not, and since
this backtick notation is used in autogenerated R code, I am stuck with devtools::check()
NOTEs that worry me.

My guess is that a lot of my setup will be similar to that of projects using C that are more
than perhaps 5 years old. I realize that my setup is a bit of a hodge-podge, docs created
by roxygen2 but NAMESPACE hand-rolled, so that might make this different from
the setup in other packages.

I wonder if anyone else has got into similar difficulties in trying to add C++
to an R project that already uses C. If so, any hints would be greatly
appreciated!

Again, I'm sorry for the length of this. I hope to have been complete enough to
describe the problem, though.

Dan Kelley, Dalhousie University