[R-pkg-devel] R package with external C++ library

[Kevin Ushey]

On Wed, Aug 3, 2016 at 3:09 PM, MTurgeon <maxime.turgeon at mail.mcgill.ca> wrote:
> Hi Ege,
>
> For writing to standard output/error, you can use Rcout or Rcerr (defined by
> Rcpp; they even have a vignette showing how to use it in the Rcpp gallery).
> Alternatively, if you're using C code, you can replace printf by Rprintf
> (this is explained in Writing R extensions, section 6.5).
>
> For abort, you can use error() instead (this is documented in WRE, section
> 6.2).

Although, please note that calling Rf_error from a C++ context is not
safe as it will skip the execution of any destructors for C++ objects
on the stack, and lead to undefined behavior in general. It's much
better to use Rcpp, Rcpp attributes, and call Rcpp::stop (which
handles this for you), or else implement this 'by hand' and throw a
C++ exception that is caught by your wrapper functions at the top
level.

> Hope this helps,
>
> Max
>
> On 2016-08-03 03:36 PM, Ege Rubak wrote:
>>
>> Hi,
>>
>> I would like to port Google's s2-library for spherical geometry (see e.g.
>> https://github.com/micolous/s2-geometry-library for a fork on GitHub). It is
>> not a standard library that can easily be installed on various systems, so I
>> would like to include the source code in the R package. The catch is that I
>> would like to modify the source code as little as possible :-)
>>
>> I have package everything and added configure scripts and a tiny
>> R-function that calls one of the C++-functions (using the antiquated .C
>> interface for now -- that will of course be changed) in this repo:
>> https://github.com/spatstat/s2
>>
>> It compiles into a working package on Ubuntu (travis-ci + my laptop), OSX
>> (travis-ci), and Windows (appveyor + my surface pro), but R CMD check
>> produces some warnings (and a note about the size of the shared object, but
>> I assume that is less important).
>>
>> The main things seem to be related to (travis log is at
>> https://travis-ci.org/spatstat/s2/jobs/149578339):
>>
>> 1. Deprecated C++ headers <ext/hash_set> and <ext/hash_map>.
>>
>> 2. Compiled code that calls entry points which might terminate R or write
>> to stdout/stderr.
>>
>> Is it hopeless to get on CRAN with warnings like these?
>> I'm not very used to writing C/C++ code, but I guess 1. can be fixed by a
>> few sed commands with the replacement headers and corresponding new function
>> names. Point 2. can probably also be fixed with a reasonable effort, but I
>> haven't investigated yet, and I would like an opinion from the list before
>> spending more time on this. In more generality the question could be phrased
>> something like:
>>
>> "When including C++ code from an upstream library which you do not control
>> should R CMD check be completely spotless or is some flexibility to be
>> expected in these circumstances?"
>>
>> Cheers,
>> Ege
>>
>> PS: Extra question (prehaps particularly aimed at Dirk): When I will
>> actually start to use the C++ library I expect it could be beneficial to use
>> Rcpp. I have seen RcppModules mentioned somewhere, and I wonder if such an
>> external C++ library would make sense to interface via RcppModules (again
>> aiming at changing upstream sources as little as possible)?
>>
>
> --
> -----------------------------------------------------------------
>
> Maxime Turgeon, PhD candidate
>
> Department of Epidemiology, Biostatistics and Occupational Health
> McGill University
>
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel