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
Using long long types in C++
8 messages · Romain Francois, Patrick Welche, Eric Malitz +3 more
On Fri, Sep 20, 2013 at 12:51:52AM +0200, romain at r-enthusiasts.com wrote:
In Rcpp we'd like to do something useful for types such as long long and unsigned long long.
...
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
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
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20130919/88badefc/attachment.pl>
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20130919/f6807cad/attachment.pl>
On 20/09/2013 03:04, Karl Millar wrote:
Romain, Can you use int64_t and uint_t64 instead? IMHO that would be more useful than long long anyway.
'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).
Karl On Sep 19, 2013 5:33 PM, "Patrick Welche" <prlw1 at cam.ac.uk> wrote:
On Fri, Sep 20, 2013 at 12:51:52AM +0200, romain at r-enthusiasts.com wrote:
In Rcpp we'd like to do something useful for types such as long long and unsigned long long.
...
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
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
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Le 20 sept. 2013 ? 02:31, Patrick Welche <prlw1 at cam.ac.uk> a ?crit :
On Fri, Sep 20, 2013 at 12:51:52AM +0200, romain at r-enthusiasts.com wrote:
In Rcpp we'd like to do something useful for types such as long long and unsigned long long.
...
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
Can you also add -std=c++0x or is that considered as bad as adding -Wno-long-long?
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
(and why not use autoconf's AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT for the tests?)
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.
Cheers, Patrick
Because
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20130920/24eb2d05/attachment.pl>
On 20-09-2013, at 03:47, Eric Malitz <eric.malitz at gmail.com> wrote:
I've been trying desperately to unsubscribe from this. Not that I don't like R; but I only wanted help and then ended up on this email list. I've put in more than one request to unsubscribe.
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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