That is similar to a path i've followed in Rcpp11/Rcpp14.
What's really missing in R is api access to strings, e.g testing for equality
of two CHARSXP, comparing them, ...
This causes all sorts of problems with dplyr.
Romain
> Le 16 déc. 2014 à 06:00, Jeroen Ooms a écrit :
>
>> On Thu, Dec
On Thu, Dec 11, 2014 at 12:24 PM, Jeroen Ooms wrote:
> I'm interfacing a c++ library which assumes strings are UTF-8. However
> strings from R can have various encodings. It's not clear to me how I
> need to account for that in Rcpp.
Follow-up on this: from what I have found, there is currently n
On Thu, Dec 11, 2014 at 2:16 PM, Dirk Eddelbuettel wrote:
> Maybe the same way? ;-)
OK I am not completely back at the C api, and it still doesn't work
when called via Rcpp:
// [[Rcpp::export]]
SEXP echo(SEXP src){
const char* utf8str = Rf_translateCharUTF8(Rf_asChar(src));
SEXP out = PROTE
On 11 December 2014 at 12:24, Jeroen Ooms wrote:
| I'm interfacing a c++ library which assumes strings are UTF-8. However
| strings from R can have various encodings. It's not clear to me how I
| need to account for that in Rcpp. For example:
|
| // [[Rcpp::export]]
| std::string echo(std::string
I'm interfacing a c++ library which assumes strings are UTF-8. However
strings from R can have various encodings. It's not clear to me how I
need to account for that in Rcpp. For example:
// [[Rcpp::export]]
std::string echo(std::string src){
return src;
}
This program does not work on windows