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

[Romain Francois]

Le 29/09/13 20:36, Simon Zehnder a écrit :
> 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.

This is not yet my concern. For now I'm focused on developping.
Releasing and supporting windows will come later.

Right now, I'm using clang on OSX to develop.

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

This has nothing to do with C++11. It is just that I fixed this issue in 
Rcpp11 and while I was there I let people know how to fix it in Rcpp. I 
might do it myself, but I might also forget to do it.

>> 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