-
-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long vector Rcpp function fails on Windows server, C function works #460
Comments
I think I might know what's wrong. I will fix it soon. |
@kendonB I am afraid this is really related to Windows. On a Ubuntu machine with 64GB memory, I used your code and I got
|
KK do you remember if either we or else R has an |
|
Being conditional on what is just before it. This is starting to ring a bell. Could someone please tell me what the size of |
Turns out we get R> library(Rcpp)
R> cppFunction("int foo() { return sizeof(size_t); }")
R> foo()
[1] 8
R> |
Not sure if this is completely obvious to y'all, but it seems the problem is in the constructor stage. See my edits to the main comment above |
Sorry but no idea what you are referring too. If you indeed know what the source of the problem is I would encourage you to submit a pull request. |
@kendonB I know the error is from ctor. First, the code from you works well on the Linux machine:
Second, since I really don't have access to a Windows machine with so many RAM, I can just guess. It might be related to how Can you check the size of Besides, can you check if the macro |
Is it possible that, for some reason, the Vector constructor on Windows is choosing the Cross-ref: https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/vector/Vector.h#L120-L131 Maybe |
Do we need |
In the I am a little curious how |
@thirdwing Size of both are 8. How do I check the |
We generally have that only with C++11: #include <Rcpp.h>
// [[Rcpp::export]]
int foo() {
#ifdef RCPP_HAS_LONG_LONG_TYPES
return 1;
#else
return 0;
#endif
}
/*** R
foo()
*/ Then in R: R> Rcpp::sourceCpp("/tmp/longlong.cpp")
R> foo()
[1] 0
R> If you add the line // [[Rcpp::plugins(cpp11)]] and re-run you get a 1. So that's not it. |
Adding
|
Is there any reason why adding
would be undesirable? |
Ahhhh, nice! Especially as we get C++11 on Windows soon too. Right now it kinda/sorta/not quite works on Windows and just gets us past some truly absurd old limits. Now, @thirdwing @kevinushey do we know why this helps it because we get the right behaviour (with compilers from this century) on OS X and Linux. What on earth breaks with 4.6.* and the old stuff? |
Yes, trust us, that has been a concern for quite some time. The best piece of advice is to just add this locally. We cannot depend on C++11 as we are fully committed to supporting all reasonable platforms. Which for RHEL4 or other dinosaurs may mean g++ 4.4.* or something older than you have. |
When you say "locally", do you mean just for personal use cases? Or would you be comfortable having it added in a CRAN package? |
So as I recall, one of the benefits of the C++11 plugin was to enable I have long relied on adding C++11 to my packages just to get So @kendonB you can add the requirement locally to your builds (via I put something into the Rcpp FAQ. Ok to close this once we document it? And thanks for finding the bug and your help. Your build with the plain C example made it clear it was us / our C++ environment. So big thanks all! |
No problem at all. I'm certainly a net drain on the open source world, so happy to contribute in small ways when I can. Happy for you to close this when you wish, of course! |
@eddelbuettel I can give a guess and might confirm it when have time. This depends on how When we test whether |
For reference, I see this in the MinGW toolchain sources (in
So I guess if you're compiling on Windows 64, and you don't have C++11 support enabled, then the (I think this just confirms all the investigation already done in this thread) |
Thank you! Exactly what I want to confirm. As I remember, ptrdiff_t is defined as long on Linux.
|
Fourth entry in Section 5: Known Issues Title: Long Vector Support on Windows Proposed Text: Prior to \R v3.0.0, the largest vector one could obtain was at most There are three options to trigger compilation with \proglang{C++11}. The first -- and most likely option to use -- will be the plugin support offered by Rcpp attributes. This is engaged by adding \code{// [[Rcpp::plugins(cpp11]]} to the top of the \proglang{C++} script. For diagnostic and illustrativative purposes, consider the following code which checks to see if \code{R_xlen_t} is available on your platform: #include <Rcpp.h>
// Force compilation mode to C++11
// [[Rcpp::plugins(cpp11]]
// [[Rcpp::export]]
int test_long_vector_support() {
#ifdef RCPP_HAS_LONG_LONG_TYPES
return 1;
#else
return 0;
#endif
}
/*** R
test_long_vector_support()
*/ The remaining two options are for users who have opted to embed Rcpp code within an R package. In particular, the second option requires adding \code{CXX_ STD = CXX11} to a \code{Makevars} file found in the \code{/src} directory. Finally, the third option is to add \code{SystemRequirements: C++11} in the package's \code{DESCRIPTION} file. Please note that the support for C++11 prior to \R v3.3.0 on Windows is limited. Therefore, plan accordingly if the goal is to support older versions of \R. |
@eddelbuettel: This issue can now be closed. |
Here is the Rcpp function (you'll need to
sourceCpp
):And the call in R:
Dirk had suggested that I try and see if this works with a plain C function, and it works:
Here is my
sessionInfo()
:Hope this helps.
The text was updated successfully, but these errors were encountered: