[Rcpp-devel] Understanding the behaviour of const CharacterVector as a function parameter

[Simon Zehnder]

Hi Romain,

thanks for this fix! 
On Sep 29, 2013, at 5:26 PM, Romain Francois <romain at r-enthusiasts.com> wrote:

> Hello,
> 
> What acts as a proxy for const CharacterVector& does not do its proxy job. Instead it gives direct access to the underlying array of SEXP that character vector use.
> 
I need some time to get this from the Rcpp source code to see what exactly is going on there - I don't have this deep understanding of the class structure, yet.

> This has been fixed in Rcpp11. The relevant addition is the const_string_proxy class. See this commit which can easily be applied to Rcpp. https://github.com/romainfrancois/Rcpp11/commit/f5e1600f7acbf3bef39325c06ef3ac5ddf8dc66a
> 
Your new rep Rcpp11 looks very interesting! I have to distribute my package not on CRAN, but at least to colleagues working on Windows machines using the Rtools package. Rtools relies on gcc 4.6 and from http://gcc.gnu.org/projects/cxx0x.html I conclude, that it does not support all features - I guess for Rcpp11 it needs at least gcc 4.7? 
On my own machine I can use it without a problem, but for the distribution among the Windows machines I fear I have to rely on the Rcpp CRAN version and use the nonconst reference as parameter. 

I am curious, what feature of C++11 does enable the const_string_proxy? 

> The commit in Rcpp11 also has removed a few things from the proxy class that I don't judge needed anymore because I'm cleaning things. This might not apply to Rcpp with its more strict compatibility requirements.
> 
I see, that the class 'generic_proxy' has gone. What was its intention in Rcpp?


Best

Simon


> Romain
> 
> Le 29/09/13 15:24, Romain Francois a écrit :
>> Le 29/09/13 14:06, Simon Zehnder a écrit :
>>> Dear Rcpp::Users and Rcpp::Devels,
>>> 
>>> I would like to understand a certain behaviour of my code I
>>> encountered lately.
>>> 
>>> I am working with CharacterVector and the following behaviour occurred:
>>> 
>>> void test1 (Rcpp::CharacterVector &charv)
>>> {
>>>    Rprintf("test1: %s\n", (char*) charv(0));
>>> }
>>> 
>>> void test2 (const Rcpp::CharacterVector &str)
>>> {
>>>    Rprintf("test2: %s\n", (char*) charv(0));
>>> }
>> 
>> Try actually using the variable you pass in, as in:
>> 
>> void test2 (const Rcpp::CharacterVector &str)
>> {
>>     Rprintf("test2: %s\n", (char*) str(0));
>> }
>> 
>> Although it still exposes the bug.
>> 
>> You can use something like this in the meantime:
>> 
>> void test2 (const Rcpp::CharacterVector& charv)
>> {
>>     String x = charv[0] ;
>>     Rprintf("test2: %s\n", x.get_cstring());
>> }
>> 
>> It looks like the bug is about converting the result of charv(0) to a
>> char*. Probably worth looking at the string_proxy class.
>> 
>> Romain
>> 
>>> Using a string like "2013-05-04 20:23:21" for the
>>> Rcpp::CharacterVector gives the following outputs:
>>> 
>>> test1: 2013-05-04 20:23:21
>>> 
>>> test2:  `
>>> 
>>> This does also not change if I use a cast to const char* in test2. I
>>> tried something similar with strings and printing the c_str() of them,
>>> there the 'const' keyword does not make a difference - it always
>>> prints the correct string.
>>> 
>>> Is this something specific to the Rcpp::CharacterVector, that uses a
>>> string_proxy for its elements returned by the operator ()? Is there a
>>> way to use const Rcpp::CharacterVector and get the behaviour of test1?
>>> 
>>> 
>>> Best
>>> 
>>> Simon
>> 
> 
> 
> -- 
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> 
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel