Romain,
I found a work-around for the VC++ problem. All I have to do
is make sure the code that is currently ifdef-ed in Extractor.h
is NOT enabled under VC++ (when _MSC_VER is defined).
Currently this code is conditionally compiled with
#ifndef IF_GCC_450_OR_LATER, so the additional condition
that _MSC_VER is NOT defined must be added, and only
the identity class at the top of Extractor.h is used.
A comment in this file suggests that you have already
observed problems under windows with Rcpp::Fast
vector extraction, presumably with MinGW/g++. The
comment goes on to say that it may be a g++ 4.5
issue and not a Windows issue. Obviously this thread
has shown that this is not the complete story.
I do not know why VC++ has a problem with
Rcpp::Fast vector extraction. With all of the pointer
manipulation it may have something to do with
incompatible word sizes, memory alignment,
or related low-level issues.
Thanks,
Dominick
On Sat, Jan 15, 2011 at 2:27 PM, Dominick Samperi <djsamp...@gmail.com>wrote:
> So that there is no confusion, I should add that the problems that I report
> here do not occur under Linux/g++ or under MinGW/g++ (the supported
> environments), where Rcpp/sugar seems to work fine.
>
>
> On Sat, Jan 15, 2011 at 1:23 PM, Dominick Samperi <djsamp...@gmail.com>wrote:
>
>>
>>
>> On Sat, Jan 15, 2011 at 4:15 AM, Romain Francois <
>> rom...@r-enthusiasts.com> wrote:
>>
>>> Le 13/01/11 16:29, Dominick Samperi a écrit :
>>>
>>> The template expression code is very interesting, but it
>>>> does not work as expected under
>>>> Windows/g++/MinGW/32bit/Rterm.exe. The problem
>>>> does not appear when I use Rgui.exe, or if I use
>>>> 64bit Windows!
>>>>
>>>> Consider the following C++ code called using
>>>> .Call('testsugar',1:5,1:5):
>>>>
>>>> RcppExport SEXP testsugar(SEXP x_, SEXP y_) {
>>>> Rcpp::NumericVector x(x_), y(y_);
>>>> Rprintf("%d, %lf, %lf\n", (x+y).size(), (x+y)[0], (x+y)[1]);
>>>> return R_NilValue;
>>>> }
>>>>
>>>> Under Linux/GCC, or 64bit Windows/g++, or
>>>> 32bit Windows/g++ I get the expected result:
>>>>
>>>> 5, 2.0, 4.0
>>>>
>>>> Under Windows/32bit/Rterm.exe I get:
>>>>
>>>> 5, 0.0, 0.0
>>>>
>>>
>>> Intriguing. Maybe Rprintf is to blame. Can you try this instead:
>>
>>
>>>
>>> RcppExport SEXP testsugar(SEXP x_, SEXP y_) {
>>> Rcpp::NumericVector x(x_), y(y_);
>>> int n = (x+y).size() ;
>>> double xy0 = (x+y)[0] ;
>>> double xy1 = (x+y)[1] ;
>>> Rprintf("%d, %lf, %lf\n", n, xy0, xy1);
>>> return R_NilValue;
>>>
>>> }
>>>
>>
>> Good guess, I found a problem with Rprintf yesterday, but this
>> will not fix it. The problem is not caused by the arbitrary evaluation
>> order of the arguments to Rprintf. It is caused by the different
>> behavior of the format control "%lf" under different architectures!
>> In particular, the problem goes away under i386/32bit Windows using
>> MinGW/g++ when "%lf" is replaced with "%f". I could not find this
>> documented anywhere.
>>
>> Of course, this has nothing to do with Rcpp, and it might
>> be of interest to r-devel.
>>
>> For me this was just a distraction because the problem with
>> Visual C++ is still alive and well and has nothing to do with
>> Rprintf. As this information might be helpful in other
>> (non-VC++) contexts here is what I am seeing.
>>
>> Consider:
>>
>>
>> RcppExport SEXP testsugar(SEXP x_, SEXP y_) {
>> Rcpp::NumericVector x(x_), y(y_);
>> Rprintf("val = %f\n", (x+y)[0]);
>> return R_NilValue;
>> }
>>
>> This goes through operator+(lhs,rhs) in plus.h, which triggers the
>> construction of an object of type Plus_Vector_Vector, and the
>> construction seems to happen without problems, because the
>> following Rprint's print what you would expect in the
>> constructor:
>>
>> Rprintf("RTYPE = %d\n", RTYPE); // get 14, REALSXP
>> Rprintf("size: %d, %d, %d\n", lhs.size(), rhs.size(), this->size()); // 5,
>> 5, 5
>> Rprintf("vals: %f, %f, %f, %f\n", lhs[0], rhs[0], lhs[1], rhs[1]); // 1.0,
>> 1.0, 2.0, 2.0
>> Rprintf("ptrs: %p, %p\n", &lhs, &rhs); // reasonable addresses
>>
>> But when you leave the constructor the two objects lhs and rhs get
>> clobbered, even though their respective addresses seem not to
>> change. In particular, the following print statements when inserted
>> into operator[](int i) show garbage (and sometimes cause a crash):
>>
>> Rprintf("ptrs: %p, %p\n", &lhs, &rhs); // this is OK, same addresses as
>> above
>> Rprintf("lhs_ = %f\n", lhs_); // 0.0 or garbage
>> Rprintf("rhs_ = %f\n", rhs_); // 0.0 or garbage
>> Rprintf("size = %d\n", lhs.size()); // usually crashes.
>>
>> Dominick
>>
>>
>>> (Under VC++ there are more serious problems including
>>>> corruption of other in the wrap-up function
>>>> Vector(VectorBase& other), but since VC++ is not
>>>> supported I will not elaborate here.)
>>>>
>>>> Thanks,
>>>> Dominick
>>>>
>>>
>>>
>>> --
>>> Romain Francois
>>> Professional R Enthusiast
>>> +33(0) 6 28 91 30 30
>>> http://romainfrancois.blog.free.fr
>>> |- http://bit.ly/fT2rZM : highlight 0.2-5
>>> |- http://bit.ly/gpCSpH : Evolution of Rcpp code size
>>> `- http://bit.ly/hovakS : RcppGSL initial release
>>>
>>>
>>> _______________________________________________
>>> Rcpp-devel mailing list
>>> Rcpp-devel@lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>>
>>
>>
>
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
