Le 19/09/13 17:39, Dirk Eddelbuettel a écrit :
On 19 September 2013 at 15:48, Romain Francois wrote:
| What I want is to change this:
|
| #if defined(__GNUC__)
| #if defined(__GXX_EXPERIMENTAL_CXX0X__) || (defined (__clang__) &&
| defined(__LP64__))
| #ifdef __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
| #endif
| #endif
|
|
| to 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
That's novel and could work. May need testing. May also need to be checked
against just using -std=c++11 / -std=c++0x which give us long long rightaway.
That just works. This is just a typedef.
Also note that Murray got a similar trick into RProtoBuf, albeit at the cost
of configure test (by finding an M4 macros which determines whether the
compiler can in fact do c++11, and if so, turns it on).
Might not be cran proof right. Last time I checked, we were not allowed
to use std=c++11 which is the gcc way of using C++ 11.
We don't need C++ 11 for long long, we just need a compiler that
supports long long in a way that does not upset cran.
| And as long as we don't actually have "long long" in code, but use
| "rcpp_long_long_type" then we are fine :
What happens when you have 'long long' via C++11? Do they coexist?
Of course. This is is the same type. __extension__ is just a way to tell
-pedantic to STFU about it.
Also not sure why you first post which seemingly asks for comments and then
still rush to commit before anyone has comments. Oh well.
You are running the Dirk compiler with the -pedantic option right ?
I've put it in because I believe it is fine, I have tested on 2 systems.
It does not mean however that I'm not welcoming comments. In particular,
I've sent a private mail to Murray asking for his thoughts.
At least, being in it has more chances to be tested.
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
