[Rcpp-devel] 64-bit ints on Windows 64-bit via size_t, unsigned long long, or unsigned __int64

[Bob Carpenter]

On 7/11/12 6:24 PM, Dirk Eddelbuettel wrote:
> Is there a reason this is off list? Can we please move it back?

No reason --- it's just that the Rcpp list is the only
list I use where "reply" doesn't go back to the
list, so I keep mistakenly replying only to Dirk.

I have an actual response inline below, but
am leaving the rest here for the list.

> On 11 July 2012 at 18:07, Bob Carpenter wrote:
> | On 7/11/12 3:52 PM, Dirk Eddelbuettel wrote:
> |
> |  > You can /absolutely/ use int64_t with Rcpp,
> |  > you simply can't upload a package using it to CRAN.
> |
> | I can't get uint64_t to work in Rcpp on Mac OS X either,
>
> For the purpose of my discussion on the list, uint64_t is the same as
> int64_t. They come from the same header, and are under the same constraint
> imposed by R Core (or one R Core member in particular, as I suspect...)
>
> | because it invokes a long long unsigned int,
> | for which there is not a template specialization
> | for an Rcpp::List element's assignment operator.
> |
> | If we specialize your templated assignment operator
> | to long long unsigned int, and have it downcast for
> | the return to R, we can get it to work in a lossy
> | way (which is OK in this context, because we'll crash R
> | before we get a 2G length array in).
>
> I think cast to either double, or string is the only way. [ I had discussions
> with a large tech firm on the west coast about this as they need unsigned
> long long index values... -- they went the more precise, but slower 'cast to
> text' route at on epoint. ]
>
> | But it doesn't work out of the box. Should it?
> | Is there another way you suggest to use int64_t in Rcpp?
>
> As I said repeatedly,

Sorry for what sounds like the same question again and again.
It's only because I didn't understand the answers.

 > I believer you have to rebuild with -std=c++11 to get
 > int64_t and long long. What exactly do I need to rebuild?  All of R?

If we add the template specialization to Rcpp's source,
we don't need to rebuild R or do anything special with
"-std=c++11" flags.  It just works.  But then we're only
testing on more recent compilers.

- Bob

Rest of context below:

>
> Dirk
>
>
> |
> | Here's the code that breaks (sysinfo below):
> |
> |  > src <- 'uint64_t b = 1; Rcpp::List x(a); x["b"] = b; return x;'
> |
> |  > fx <- cxxfunction(signature(a = 'list'), body=src, includes='',
> | plugin='Rcpp', verbose = FALSE)
> |
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/internal/wrap.h:
> | In function ‘SEXPREC*
> | Rcpp::internal::wrap_dispatch_unknown_iterable(const T&,
> | Rcpp::traits::false_type) [with T = long long unsigned int]’:
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/internal/wrap.h:638:
> | instantiated from ‘SEXPREC* Rcpp::internal::wrap_dispatch_unknown(const
> | T&, Rcpp::traits::false_type) [with T = long long unsigned int]’
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/internal/wrap.h:654:
> | instantiated from ‘SEXPREC* Rcpp::internal::wrap_dispatch_eigen(const
> | T&, Rcpp::traits::false_type) [with T = long long unsigned int]’
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/internal/wrap.h:669:
> | instantiated from ‘SEXPREC*
> | Rcpp::internal::wrap_dispatch_unknown_importable(const T&,
> | Rcpp::traits::false_type) [with T = long long unsigned int]’
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/internal/wrap.h:687:
> | instantiated from ‘SEXPREC* Rcpp::internal::wrap_dispatch(const T&,
> | Rcpp::traits::wrap_type_unknown_tag) [with T = long long unsigned int]’
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/internal/wrap.h:791:
> | instantiated from ‘SEXPREC* Rcpp::wrap(const T&) [with T = long long
> | unsigned int]’
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/vector/proxy.h:155:
> | instantiated from ‘Rcpp::internal::generic_name_proxy<RTYPE>&
> | Rcpp::internal::generic_name_proxy<RTYPE>::operator=(const T&) [with T =
> | uint64_t, int RTYPE = 19]’
> | file787979d08b.cpp:30: instantiated from here
> | /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/internal/wrap.h:433:
> | error: invalid conversion from ‘const long long unsigned int’ to ‘SEXPREC*’
> | make: *** [file787979d08b.o] Error 1
> |
> |
> |  > sessionInfo()
> | R version 2.15.1 (2012-06-22)
> | Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
> |
> | locale:
> | [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> |
> | attached base packages:
> | [1] stats graphics grDevices utils datasets methods base
> |
> | other attached packages:
> | [1] inline_0.3.8 Rcpp_0.9.13
> |
> | loaded via a namespace (and not attached):
> | [1] tools_2.15.1
> |
> | > There is nothing I can do about the latter part (and I suggest you take the
> | > issue to r-devel).
> |
> | Nice software support judo!
> |
> | Given the attitude expressed in "Writing R Extensions", something
> | tells me that wouldn't be a fruitful discussion. This quote
> | pretty much says it all: "It is rather unlikely
> | that the use of `long' in C code has been thought through:"
> |
> | I totally understand the Rcpp developers can't control what R
> | does and you have to live with it.
> |
> | > So until CRAN considers C++11 a working standard (and all recent compilers
> | > can support it) we will not have 'long long' in C++.
> |
> | The R developers have a longer view of "recent" than we do
> | (which I can also understand given their installed user
> | base with ancient hardware and software).
> |
> | All of g++ (4.2+, at least), clang++ (2.9+, at least)
> | and MSVC (whatever we downloaded last) support long long and
> | don't even gripe about it being a C++ feature -- they do not
> | need any special flags.
> |
> | - Bob
> |
> |
>