Skip to content

Using long long types in C++

8 messages · Romain Francois, Patrick Welche, Eric Malitz +3 more

#
Hello,

In Rcpp we'd like to do something useful for types such as long long 
and unsigned long long.

For example, supporting our usual wrap construct. We'd like to be able 
to "wrap" a long long, or perhaps a std::vector<long long> so that it is 
returned to the R side in something meaningful (we are considering 
several options like loosing some precision and returning an int, 
loosing a bit less precision and returning a double or use bit shifting 
tricks and do something compatible with the bit64 package).

To do this, we try to be careful and hide the code behind these two PP 
tests:

#if defined(__GNUC__) &&  defined(__LONG_LONG_MAX__)

which tests for gcc compatible (includes clang) compiler and the 
availability of the long long type.


Now this is not enough and we also have to use __extension__ to disable 
warnings that are emitted by -pedantic. So we have something like this:

#if defined(__GNUC__) &&  defined(__LONG_LONG_MAX__)
     __extension__ typedef long long int rcpp_long_long_type;
     __extension__ typedef unsigned long long int rcpp_ulong_long_type;
     #define RCPP_HAS_LONG_LONG_TYPES
#endif

and for the rest of what we do with these types, we use 
rcpp_long_long_type and rcpp_ulong_long_type and hide the code behind 
#if defined(RCPP_HAS_LONG_LONG_TYPES)


But apparently this is still not enough and on some versions of gcc 
(e.g. 4.7 something), -pedantic still generates the warnings unless we 
also use -Wno-long-long


Dirk tells me that the fact that these warnings show up means that it 
would not be accepted in CRAN. I understand that -pedantic is useful for 
finding potential portability problems, but in that case I believe 
everything is done to isolate the use of long long to a situation where 
we know we can use it given that we test for a compiler (gcc) and its 
known way to check for existence of long long: __LONG_LONG_MAX__

What are my options here ?

Romain
#
On Fri, Sep 20, 2013 at 12:51:52AM +0200, romain at r-enthusiasts.com wrote:
...
Can you also add -std=c++0x or is that considered as bad as adding
-Wno-long-long?

(and why not use autoconf's AC_TYPE_LONG_LONG_INT and
AC_TYPE_UNSIGNED_LONG_LONG_INT for the tests?)

Cheers,

Patrick
#
On 20/09/2013 03:04, Karl Millar wrote:
'Writing R Extensions' does say

'Do be very careful with passing arguments between R, C and FORTRAN 
code. In particular, long in C will be 32-bit on some R platforms 
(including 64-bit Windows), but 64-bit on most modern Unix and Linux 
platforms. It is rather unlikely that the use of long in C code has been 
thought through: if you need a longer type than int you should use a 
configure test for a C99 type such as int_fast64_t (and failing that, 
long long 42) and typedef your own type to be long or long long, or use 
another suitable type (such as size_t).

Note that int64_t is not portable, even in C99, since its implementation 
is optional.
On 20/09/2013 01:31, Patrick Welche wrote:
>
 > Can you also add -std=c++0x or is that considered as bad as adding
 > -Wno-long-long?

That is not portable.  It is g++ specific and AFAIR not accepted by the 
version of g++ used on OS X (which dates from 2007).

  
    
#
Le 20 sept. 2013 ? 02:31, Patrick Welche <prlw1 at cam.ac.uk> a ?crit :
IIRC, a package on CRAN is not allowed to change -std, there is or at least was barriers to forbid this. 

Plus, some of us use the default settings on OSX, this is still (simili) gcc 4.2.1 which has long long but does not implement c++11
Because no matter how many precautions we take, if at the end of the day we end up having mentions of long long in the code, even behind sufficient test, it will still generate warnings which i'm told would prevent the cran distribution of the package. 

I'd really like to hear from cran maintainers on this.
Because
#
On 20-09-2013, at 03:47, Eric Malitz <eric.malitz at gmail.com> wrote:

            
Then surf to the address given at the end of each posting; go to the bottom of that page and follow the instructions for unsubscribing.

Berend