allow long long on 64bit windows

[kevinushey]

Fixes #804. Because the compiler toolchain on Windows provides long long regardless of whether C++98 or a newer standard is requested, this usage should be permissible on CRAN.

In addition, because R_xlen_t and std::size_t are actually defines for long long and unsigned long long on 64bit Windows, those constructors now work 'for free'.

[krlmlr]

Thanks @kevinushey for looking into it!

[eddelbuettel]

@kevinushey on win-builder r-devel I get:

* checking whether package 'Rcpp' can be installed ... WARNING
Found the following significant warnings:
  ../inst/include/Rcpp/longlong.h:43:14: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long]
  ../inst/include/Rcpp/longlong.h:44:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long]
See 'd:/RCompile/CRANguest/R-devel/Rcpp.Rcheck/00install.out' for details.
* checking installed package size ... 

Do we need additional C++11 protection around these?

[kevinushey]

grumbles loudly

Let me think about whether there's an alternate mechanism by which we can get a 64bit integer type on Windows. I'd love for this to work even without C++11 but worst case scenario we can just add that in.

[eddelbuettel]

I am 100% certain that we fought these dragons many times before. And at some point I just gave it a major fsck this as you cannot argue away the sillyness of the is C++ 1998 (hey, twenty years) requirement for an entirely irrelevant standard.

But long and short, unless users opt into C++11 (as eg my RcppBDT for Boost date_time did maybe six years ago) to get long long they simply will not get them on 'doze. C'est la vie

I would be delighted to be proven wrong but don't expect it.

[eddelbuettel]

Ok, win-builder came back with a thumbs up and I suggest that we go fix this fix:

modified   inst/include/Rcpp/longlong.h
@@ -40,9 +40,11 @@ __extension__ typedef unsigned long long int rcpp_ulong_long_type;
 
 // The Rtools toolchain provides long long on 64bit Windows
 #ifdef _WIN64
+#ifdef RCPP_USING_CXX0X_OR_LATER
 typedef long long rcpp_long_long_type;
 typedef unsigned long long rcpp_ulong_long_type;
 #define RCPP_HAS_LONG_LONG_TYPES
 #endif
+#endif

Any objections? I will be less 'global' that what @krlmlr had hoped but such is life when our good friends insist on C++98 for reasons way beyond our comprehension.

[kevinushey]

I'm going to take another look at this so may follow up with another PR.

[kevinushey]

(but if I fail I think that will be the right change)

[krlmlr]

Can we just set CXX_STD=CXX11 in Makevars.win? Worked for me in RSQLite and friends, I'm using int64_t there without problems. (Thanks @jeroen for the tip!)

[eddelbuettel]

@krlmlr Yes the 'use C++11' trick has worked (and been used) for many many years.

@kevinushey ok

[krlmlr]

Do I understand correctly that we can't just add in CXX_STD=CXX11 to Makevars.win in Rcpp? Or is it about packages having to opt in to use C++11?

Can we add some protection to avoid the underlying issue to occur in the future? I'd like to see an error or a warning if a vector constructor is called with an R_xlen_t and this is silently coerced to a 32-bit integer.

[eddelbuettel]

We didn't do this for Rcpp as we would then force down a newer compiler. @jjallaire usually reminds us of the numerous old RHEL instances still trying to build it.

We impose a new(er) compiler for RcppArmadillo and get occassional issues back, see its issue tickets.

As for R_xlen_t and 32-bit: that is a) an R issue I believe them to handle well enough and b) on the other hand 32 bit machines are on their way out too... The main issue, really, is Windows where we now have g++ 4,9.3 which while far from ideal is a huge step up from the 4.6.2 dinosaur before it.

[krlmlr]

I'm only suggesting to enable C++11 on Windows. Would that work?

[eddelbuettel]

Maybe. But I don't like the idea of splitting standards. And 4.9.3 is not really C++11 compliant, it just pretends to be. (For RcppCCTZ we ported something from the C++ Std Lib back.)

And the patch by @kevinushey is functionally equivalent.