0

I'm experiencing .Call issues when running functions built with Rcpp on Windows, if my c++ code uses C++11 std::regex and I have found no way out so far.

Unlike prior questions on similar issues, I have had neither building nor linking issues. The Rcpp package builds and links fine using the C++11 plugin, making usable packages on my platform. constexpr and C++11-specific functions like std::stoi cause no issue when std::regex is not used.

Using Windows boost libs, I experienced linking issues, even when specifying PKG_LIBS="-L/path/to/boost/libs -lboost_regex", so I'd rather stick to std::regex.

The same packages build, install and run fine under linux, using vanilla std::regex or boost::regex.

I unfortunately found no solution in the fine Rcpp gallery examples.

Windows platform is : 

R version 3.2.3 (2015-12-10)   
x86_64-w64-mingw32/x64 (64-bit)

Running under: 

Windows >= 8 x64 (build 9200)  
Rcpp_0.12.3   
Rtools 3.3.0.1959 running g++ 4.9.3 (x86_64-posix-seh, 
built by MinGW-W64 project), normally C++11-compatible.  
PKG_CXXFLAGS="-std=c++11"

The linux platform is similar except for g++ (version 5.3).

Below is a simplified code chunk for duplication.

#include <Rcpp.h>
#if defined(__linux__) && ! defined(FORCE_STL_BUILD)
  #include <boost/regex.hpp>
  #define reglib boost
#else
 #include <regex>
  #define reglib std
#endif

#include <string>

using namespace Rcpp;
// [[Rcpp::plugins(cpp11)]]

constexpr int a[3]= {2, 10, 15};

 // [[Rcpp::export]]  
int my_test(int prop, const std::string& index)   
 {
   #ifndef NO_REG
      static const reglib::regex test {"H.*A", reglib::regex::icase};
   #endif
   int index_int =  std::stoi(index) + a[1] + prop;
   return index_int;
 }

This code runs OK when built using -DNO_REG. Otherwise invoking test::my_test(1, "1000") returns: 

  `Error in .Call("test_my_test", PACKAGE = "test", prop, index) : 
      "test_my_test" not available for .Call() for package "test"`

EDIT:
1. The question focuses on std::regex. Boost issues are only incidental comments.
2. Issues only arise after packaging, not using Rcpp::source("cppfile")
3. Packaging code:
R console: 

     Rcpp::Rcpp.package.skeleton("test", attributes=TRUE, example_code=FALSE, cpp_files="test.cpp")     
     Rcpp::compileAttributes("test")

CMD console: 

     REM paths to R/bin/x64 and Rtools/bin, Rtools/mingw_64/bin added to PATH         
     set PKG_CXXFLAGS=-std=c++11      
     R CMD build test    
     R CMD INSTALL test_1.0.tar.gz

ADDITIONAL EDIT:
.Call issues arise as soon as a regex is declared in the C++ code. Using it or no (as in std::regex_match) makes no change.

Fab
  • 1
  • 1

1 Answers1

1

Can you try disentangling this some more? You are mixing a lot of things here.

Try maybe 'just' C++ from R first, with the newer g++ 4.9.3 compiler and see if that lets you use Boost as you hope. Your use case there is local and non-standard, so you have to work this out. We generally just recommend using BH without linking.

I don't actually see an Rcpp issue here. You are simply pushing the (working, tested, trusted) Rcpp setup into a corner it has not been used in yet. So you may need to work some things out yourself.

Also note that g++ 4.9.3 for R is not really released yet.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • In short: a) mentioned issues do not arise using sourceCpp("test.cpp"). So yes, it is not actually an Rcpp issue but an Rcpp-related packaging snag. b) I'm surprised at your comment that g++ 4.9.3 for R is not released yet: the vanilla RTools 3.3 Windows package ships with g++4.9.3 and nothing else. c) Ever since std::regex was incorporated into the standard, using it has been run-of-the-mill C++11 programming. So I do not think that I'm pushing Rcpp into a corner with *non-standard* code-- just writing plain modern C++. – Fab Feb 22 '16 at 15:29
  • Can you detail what the supposed 'snag' is and then maybe file an issue ticket? As for Rtools, see [here](https://cran.r-project.org/bin/windows/Rtools/) -- it is a little 'inside baseball' but "Frozen: no" means to finalised. And not yet used for R releases. But it is a good idea to test it. – Dirk Eddelbuettel Feb 22 '16 at 16:00
  • Issue ticket filed on github in a somewhat narrowed-down form. – Fab Feb 22 '16 at 18:45
  • No! Why should I have? – Fab Feb 22 '16 at 22:45