On Wed, Aug 3, 2016 at 3:09 PM, MTurgeon <maxime.turg...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
