Skip to content

[Rcpp-devel] long long

21 messages · Dirk Eddelbuettel, Romain Francois, Smith, Dale (Norcross) +1 more

Original
Romain Francois
# 
(rebrand as a Rcpp-devel question)

Le 19/09/13 13:58, Romain Francois a ?crit :
And if compile this file with -Wall -pedantic. I don't get issues:

#include <Rcpp.h>
using namespace Rcpp ;

__extension__ typedef long long int rcpp_long_long_type;

// [[Rcpp::export]]
int foo(){
	rcpp_long_long_type x = 2 ;
	return (int)x;
}


But if I remove the __extension__ thing, I get the warning:

$ RcppScript longlong.cpp
longlong.cpp:4: error: ISO C++ does not support ?long long?
make: *** [longlong.o] Error 1
llvm-g++-4.2 -arch x86_64 
-I/Library/Frameworks/R.framework/Resources/include -DNDEBUG 
-I/usr/local/include 
-I"/Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/include" 
   -Wall -pedantic -fPIC  -mtune=core2 -g -O2  -c longlong.cpp -o longlong.o
Erreur dans sourceCpp(file) : Error 1 occurred building shared library.
Ex?cution arr?t?e

-pedantic gives us the warning when it sees us writing long long, but if 
we just hide it behind __extension__ it does not complain no more.


So we should be able to just use __LONG_LONG_MAX__ and if people want to 
use long long in their code, they use rcpp_long_long_type or maybe we 
alias it to something sweater (LONG_LONG) perhaps ?


Romain
Dirk Eddelbuettel
#
On 19 September 2013 at 14:18, Romain Francois wrote:
| (rebrand as a Rcpp-devel question)

I just re-explained it on our internal rcpp-core list. The same points were
all made here too circa 2010 and are in the list archives.

In short, we are up against a CRAN Policy which wants

  i)   "standards compliant code" put unfortunately insists on a 15 year old
       standard (C++98)

  ii)  "portable code" as it maintains that there are compilers not named g++
       or clang++ which matter (which I sort of agree with on theoretical
       grounds, in practice I'd be ready to differ).

But in short it is not our call.  If we want Rcpp to be on CRAN (and I
maintain that we do) then we do NOT get long long.  At least not yet.

But I guess by the time we all are retired CRAN may allow the C++11 standard.

Dirk
Romain Francois
# 
Le 19/09/13 15:30, Dirk Eddelbuettel a ?crit :
Sure. You explained what you think is right. I disagree. Let me explain 
a bit more then.
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


In both cases, we have artifacts of non portability, i.e. the 
__extension__ thing, but in both cases they are hidden behind 
defined(__GNUC__) so only enabled for gcc compatible compiler (so gcc 
and clang).


But in what I propose, we can actually make something useful for long 
long types, which we would have to use as rcpp_long_long_type for more 
settings. For example, with this version of gcc on the mac, I have long 
long but I can't use it:

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.11.00)

If I follow your argument, neither what is currently in Rcpp not what I 
propose should be in Rcpp.

Writing portable code is about settling on the lowest common denominator 
but enable more things for more capable compilers when we know we use them.


Anyway, i can install Rcpp on both my OSX machine and your ubuntu with 
gcc 4.4.7-2, compiling it with -pedantic in both cases and not get these 
warnings.

And as long as we don't actually have "long long" in code, but use 
"rcpp_long_long_type" then we are fine :

 > demangle( "rcpp_long_long_type" )
[1] "long long"
 >
 > demangle( "long long" )
file76776fc6e118.cpp: In function ?SEXPREC* manipulate_this_type()?:
file76776fc6e118.cpp:8: warning: ISO C++ 1998 does not support ?long long?
[1] "long long"

So we get the warnings because we explicitely write "long long" in code.


What I propose is as much (un)portable as what we have, it just is more 
useful when it can be.

Romain
Romain Francois
# 
I've put it in with some text explaining it.

// long long and unssigned long long support.
//
// given the current restriction of what might go to CRAN
// we can only use long long if we are running a gcc compatible (e.g. clang)
// compiler and the type is actually available (hence the test for 
__LONG_LONG_MAX__)
// even then, we cannot use long long as is, we first have to "hide" it
// behind the __extension__ so that -pedantic stops giving warnings about
// compliance with C++98
//
// client code may use the facilities we provide for long long (wrap, 
etc ...)
// but not using long long directly, because then it is not CRAN proof.
// So client code must use the rcpp_long_long_type and rcpp_ulong_long_type
// types
//
// e.g. code like this is not good:
//
// long long x = 2 ;
//
// but code like this is CRAN proof
//
// rcpp_long_long_type x = 2 ;
//
// Note that if you don't distribute your code to CRAN and you don't use 
the
// -pedantic option, then you can use long long
#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

I'll start a discussion on R-devel if needed.



For now this gives us wrap<rcpp_long_long_type> and wrap< 
vector<rcpp_long_long_type> >, etc ... that for now generate numeric 
vector (so for a precision going up to 52 or 53(I can never remember 
this one) bits of precision, so better than what it used to be (32).

It might be worth investigating generating something compatible with the 
bit64 or the int64 package.

int64 stores a long long vector as a list of integer vectors of length 2.

bit64 is smarter and uses the bits of a double. And it is faster, as its 
documentation cares to show in great detail.

Other packages (e.g. data.table) have adopted the way bit64 does it. And 
it does not require that we depend on bit64. That's what 
data.table::fread does when reading integer64 columns: it stores them as 
a numeric vector with the appropriate class suitabe for bit64. Then if 
bit64 is loaded then the object is treated as a 64 bit integer vector. 
If it is not loaded, the values are just weird looking numeric vector.

Even though I wrote int64, I might actually lean towards generating 
something to play along with bit64 rather than int64.

However bit64 does not seem to implement unsigned 64 bit vectors (i.e. 
rcpp_ulong_long_type, aka unsigned long long).

Romain

Le 19/09/13 15:48, Romain Francois a ?crit :

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
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.

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).

| 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?

Also not sure why you first post which seemingly asks for comments and then
still rush to commit before anyone has comments.  Oh well.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
Le 19/09/13 17:39, Dirk Eddelbuettel a ?crit :

            

      
      
      
    

        
That just works. This is just a typedef.

            

      
      
      
    

        
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.

            

      
      
      
    

        
Of course. This is is the same type. __extension__ is just a way to tell 
-pedantic to STFU about it.

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
Darn. Romain's change look promising, but it seems that even with R-release I
get a bunch of warnings which would prevent this from going to CRAN.  Maybe
the status quo wasn't so bad after all.

Current SVN head as below. Ubuntu 13.03, 64bit. G++ 4.7.3 selected via CXX in
the file ~/.R/Makevars

Dirk

edd at max:~/svn/rcpp/pkg$ svn info
Path: .
Working Copy Root Path: /home/edd/svn/rcpp
URL: svn+ssh://edd at svn.r-forge.r-project.org/svnroot/rcpp/pkg
Repository Root: svn+ssh://edd at svn.r-forge.r-project.org/svnroot/rcpp
Repository UUID: edb9625f-4e0d-4859-8d74-9fd3b1da38cb
Revision: 4521
Node Kind: directory
Schedule: normal
Last Changed Author: romain
Last Changed Rev: 4521
Last Changed Date: 2013-09-19 10:16:41 -0500 (Thu, 19 Sep 2013)

edd at max:~/svn/rcpp/pkg$ R CMD check --no-vignettes Rcpp_0.10.4.5.tar.gz 
* using log directory ?/home/edd/svn/rcpp/pkg/Rcpp.Rcheck?
* using R version 3.0.1 (2013-05-16)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* using option ?--no-vignettes?
* checking for file ?Rcpp/DESCRIPTION? ... OK
* this is package ?Rcpp? version ?0.10.4.5?
* checking CRAN incoming feasibility ... OK
Maintainer: ?Dirk Eddelbuettel <edd at debian.org>?
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ?Rcpp? can be installed ... WARNING
Found the following significant warnings:
  ../inst/include/Rcpp/platform/compiler.h:205:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:206:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:205:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:206:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:205:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:206:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:205:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:206:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:205:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:206:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:205:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
  ../inst/include/Rcpp/platform/compiler.h:206:19: warning: ISO C++ 1998 does not support ?long long? [-Wlong-long]
See ?/home/edd/svn/rcpp/pkg/Rcpp.Rcheck/00install.out? for details.
* checking installed package size ... NOTE
  installed size is 24.7Mb
  sub-directories of 1Mb or more:
    doc       2.0Mb
    include   6.3Mb
    lib      11.6Mb
    libs      3.4Mb
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking for portable compilation flags in Makevars ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking compiled code ... OK
* checking sizes of PDF files under ?inst/doc? ... OK
* checking installed files from ?inst/doc? ... OK
* checking examples ... OK
* checking for unstated dependencies in tests ... OK
* checking tests ...
  Running ?doRUnit.R? [103s/91s]
 [104s/92s] OK
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in ?inst/doc? ... OK
* checking running R code from vignettes ... SKIPPED
* checking re-building of vignettes ... SKIPPED
* checking PDF version of manual ... OK

WARNING: There was 1 warning.
NOTE: There was 1 note.
See
  ?/home/edd/svn/rcpp/pkg/Rcpp.Rcheck/00check.log?
for details.

edd at max:~/svn/rcpp/pkg$

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
What's in your Makevars.

I'm not able to reproduce this on __your__ machine with whatever are the 
defaults.

Romain

Le 19/09/13 18:32, Dirk Eddelbuettel a ?crit :

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 19 September 2013 at 17:54, Romain Francois wrote:

        
| > 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.

Nope. See my follow-up.
 
| > 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.

Well have a look at what he does in configure for RProtoBuf:

  # If we can support std=c++0x we should pass flags to do so (this will
  # enable better int64 support) but we shouldn't cause the build to
  # fail if we can't do this.
  AC_CXX_COMPILE_STDCXX_0X

which uses an m4 macro he borrowed from somewhere else.
 
| 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.

He reads this list too. No read to rush.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 19 September 2013 at 19:01, Romain Francois wrote:

        
| What's in your Makevars.

Try this 

   $ cat ~edd/.R/Makevars

and or cust do

   $ test -d ~/.R || mkdir ~/.R
   $ cp -vax ~edd/.R/Makevars ~/.R

| I'm not able to reproduce this on __your__ machine with whatever are the 
| defaults.

"Defaults" is not defined here. In case you refer to g++ (4.4) it is
irrelevant as Kurt uses whatever Debian testing gives him (4.8 right now). I
have a libvirt instance on the server running Debian too.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
Alright, so with these settings -pedantic turns on -Wlong-long

I can disable them with -Wno-long-long

Can we detect gcc with a configure and set -Wno-long-long, is that allowed ?

Where in the CRAN policies does it say that -pedantic should be used ? I 
did not find it.



We don't actually "compile" code that needs rcpp_long_long_type in Rcpp 
(in the .cpp files), so I might have an idea to move this problem.

We could put this behind another define, like this:

#if defined(RCPP_LONG_LONG_SUPPORT)
#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
#endif

so that Rcpp compiles fine, and if someone wants to use it, then in 
their code thay can :

#define RCPP_LONG_LONG_SUPPORT
#include <Rcpp.h>

On your machine with your settings, this no longer warns.

Romain


Le 19/09/13 18:32, Dirk Eddelbuettel a ?crit :

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 19 September 2013 at 20:08, Romain Francois wrote:

        
| Alright, so with these settings -pedantic turns on -Wlong-long
| 
| I can disable them with -Wno-long-long
| 
| Can we detect gcc with a configure and set -Wno-long-long, is that allowed ?
| 
| Where in the CRAN policies does it say that -pedantic should be used ? I 
| did not find it.

Where does it say that CRAN Policies are fully specified and written out?  

Please just take my word for it based on a few years of dealing with Kurt and
CRAN, and / or experiment yourself with a small (new ?) package of yours. 

Because this will not fly I would prefer that the change be rolled back.

People who really need long long already have an easy hook:  -std=c++11

| We don't actually "compile" code that needs rcpp_long_long_type in Rcpp 
| (in the .cpp files), so I might have an idea to move this problem.
| 
| We could put this behind another define, like this:
| 
| #if defined(RCPP_LONG_LONG_SUPPORT)
| #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
| #endif
| 
| so that Rcpp compiles fine, and if someone wants to use it, then in 
| their code thay can :
| 
| #define RCPP_LONG_LONG_SUPPORT
| #include <Rcpp.h>
| 
| On your machine with your settings, this no longer warns.

Sure, but this seems like is bike-shedding: A local variant already had this
by simply adding -std=c++11 as C++ post-1998 has long long types.  Now you
just renamed the handle, for no real tangible benefit.  I know this is
frustrating, and I don;t mean to be difficult.  But if we fight a fight with
CRAN, let's fight over C++11.  This issue here does not really matter.

And personally, I'd prefer a bit more stability in our core headers.  The
previous setting worked for a number of years.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
Le 19/09/13 20:53, Dirk Eddelbuettel a ?crit :

            

      
      
      
    

        
>

            

      
      
      
    

        
Which does not work for me.

            

      
      
      
    

        
We could have an if between c++11 or this define. This way it works for 
me __and__ as before. Can you handle that.

            

      
      
      
    

        
You want stability, I want to make progress. The same fight all over again.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 19 September 2013 at 21:20, Romain Francois wrote:

        
| Le 19/09/13 20:53, Dirk Eddelbuettel a ?crit :
| > People who really need long long already have an easy hook:  -std=c++11
| 
| Which does not work for me.

I don't follow. What does not work? Your compiler does not support it? You
have no ~/.R/Makevars file to set it?
 
| We could have an if between c++11 or this define. This way it works for 
| me __and__ as before. Can you handle that.

Sure. If it doesn;t break anything (and it would be nice if you could run the
tarball against R-devel and a current compiler to once or twice; if your OS X
isn't ready win-builder is useful).

| You want stability, I want to make progress. The same fight all over again.

As usual I want it all:  progress without foregoing stability / backwards compat.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
Just to bring closure to this thread: Per Section 1.7 of the "Writing R
Extensions" manual, the 'C++98' standard, without any C99 extensions, is
prescribed by CRAN.

That explicitly excludes long long. So we are back to where we were years
ago: you only get 'long long' in Rcpp if you enable the '-std=c++11' (or
-std=c++0x') extensions not allowed at CRAN.

Sadly, two of the R manuals also (falsely) claim that no C++11 compliant
compilers exist. That changed in the summer of 2013, and I plan to file a bug
report against the manuals once R 3.0.2 is out next week.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
Le 2013-09-20 14:24, Dirk Eddelbuettel a ?crit?:

            

      
      
      
    

        
That is not the way I read it. It says to use the tools given by the 
compiler to find potential problems.
Fine. Done that. Identified the portability problem, dealing with it 
with conditional compilation. Prooving it. Not good enough ?

As people might have seen on other channels (twitter). I'm forking Rcpp 
into Rcpp11. This will be a version that enforces C++11.

I'm not expecting to be able to distribute Rcpp11 on CRAN, but Dirk 
probably will keep maintaining Rcpp.
I'll have to figure out where and how to distribute Rcpp11. It should 
not be too hard to come up with a repository that complies with 
install.packages.

CRAN is an amazing resource and a huge part of the success of R. Rcpp11 
will need a different repo, so be it. Maybe in the long run, I'll be 
able to show that it was worth experimenting on C++11, maybe not. I'm 
just moving away from this problem.

Romain

PS: I'm still interested in some constructive discussion about the 
original question.

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Smith, Dale (Norcross)
    

    

      
      #
    

  


  

      
I agree with Romain's approach, which I was going to send later today:

" After reading this thread and others, I would tentatively suggest maintaining a C++11 compliant version on r-forge for those who need it. I do recognize this is additional work, but may be worth the effort. A case can be made here that CRAN, which is not allowed to change compilers, may develop a conflict with Rcpp and its growing user community."

Dale Smith, Ph.D.
Senior Financial Quantitative Analyst
Financial & Risk Management Solutions
Fiserv
Office: 678-375-5315
www.fiserv.com


-----Original Message-----
From: rcpp-devel-bounces at r-forge.wu-wien.ac.at [mailto:rcpp-devel-bounces at r-forge.wu-wien.ac.at] On Behalf Of romain at r-enthusiasts.com
Sent: Friday, September 20, 2013 8:41 AM
To: Dirk Eddelbuettel
Cc: rcpp-devel at r-forge.wu-wien.ac.at
Subject: Re: [Rcpp-devel] long long

Le 2013-09-20 14:24, Dirk Eddelbuettel a ?crit?:

            

      
      
      
    

        
That is not the way I read it. It says to use the tools given by the compiler to find potential problems.
Fine. Done that. Identified the portability problem, dealing with it with conditional compilation. Prooving it. Not good enough ?

As people might have seen on other channels (twitter). I'm forking Rcpp into Rcpp11. This will be a version that enforces C++11.

I'm not expecting to be able to distribute Rcpp11 on CRAN, but Dirk probably will keep maintaining Rcpp.
I'll have to figure out where and how to distribute Rcpp11. It should not be too hard to come up with a repository that complies with install.packages.

CRAN is an amazing resource and a huge part of the success of R. Rcpp11 will need a different repo, so be it. Maybe in the long run, I'll be able to show that it was worth experimenting on C++11, maybe not. I'm just moving away from this problem.

Romain

PS: I'm still interested in some constructive discussion about the original question.

            

      
      
      
    

        
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel at lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 20 September 2013 at 12:47, Smith, Dale (Norcross) wrote:

        
| " After reading this thread and others, I would tentatively suggest
| maintaining a C++11 compliant version on r-forge for those who need it. "

Go for it.  

If you re-read Romain's mail(s) it will become that he is unlikely to put
this onto R-Forge.  

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
Le 20 sept. 2013 ? 15:37, Dirk Eddelbuettel <edd at debian.org> a ?crit :

            

      
      
      
    

        
True. I'm hosting Rcpp11 on github which I prefer over r-forge.

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Kasper Daniel Hansen
    

    

      
      #
    

  


  

      
I don't know why this thread only popped up now in my gmail; I have been
following it on R-devel.

I have just skimmed the extensive discussion, but I just want to add a few
things
  - presently, the default compiler on OS X Mountain Lion is not clang,
which is what Romain was testing with, but a stock GCC.  Difference is this:

sleipner-1 $ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
sleipner-1 $ /usr/bin/gcc-4.2 --version
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  - Aside from GCC and clang, I would say the Intel compilers are worth
thinking about for serious use.

I don't know how hard this is to do, but I guess the "right" way to deal
with this is to use autoconf to detect all of this and then use something
like
  R_CPP_HAS_C11++
with some stub for throwing an error if a feature is used on a platform not
supporting R_CPP.  That should work for simple examples, but it may be hard
to do the autoconf test.  And of course, Rcpp is anything but "a simple
example" so I don't even know if this is possible in theory.

Anyway, I know this is mostly noise, but wanted to remind you of the OS X
issue.

Best,
Kasper



On Fri, Sep 20, 2013 at 8:47 AM, Smith, Dale (Norcross) <

        
Dale.Smith at fiserv.com> wrote:

        

            

      
      
      
    

        

      
      
    

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130920/bec57a62/attachment-0001.html>

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 20 September 2013 at 09:46, Kasper Daniel Hansen wrote:

        
| I don't know why this thread only popped up now in my gmail; I have been
| following it on R-devel.

In case you really care the full thread (incl your post) is 

   http://thread.gmane.org/gmane.comp.lang.r.rcpp/6057

but as I said we went over all these C++98 already years ago. Nothing new
here until CRAN changes allows more than C++98.
 
| I have just skimmed the extensive discussion, but I just want to add a few
| things
| ? - presently, the default compiler on OS X Mountain Lion is not clang, which
| is what Romain was testing with, but a stock GCC. ?Difference is this:
| 
| sleipner-1 $ /usr/bin/gcc --version
| Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
| --with-gxx-include-dir=/usr/include/c++/4.2.1
| Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
| Target: x86_64-apple-darwin12.5.0
| Thread model: posix
| sleipner-1 $ /usr/bin/gcc-4.2 --version
| i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
| Copyright (C) 2007 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions. ?There is NO
| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

We are aware of this. 

It is a very unfortunate situtation (between Apple and teh FSF) which some at
CRAN seem to use to impose truly awful minimal standard (eg C++98).
 
| ? - Aside from GCC and clang, I would say the Intel compilers are worth
| thinking about for serious use.
| 
| I don't know how hard this is to do, but I guess the "right" way to deal with
| this is to use autoconf to detect all of this and then use something like
| ? R_CPP_HAS_C11++

Murray did something similar for RProtoBuf (which I mentioned to Romain as well):

  # If we can support std=c++0x we should pass flags to do so (this will
  # enable better int64 support) but we shouldn't cause the build to
  # fail if we can't do this.
  AC_CXX_COMPILE_STDCXX_0X

It is transparent. On compilers that can, we get C++111. No need for forks.
That said, if CRAN knew that we did this, I am not sure they'd be happy.  But
given that Kurt already runs hundreds of configure tests for R, why not add
this one?  I will try to push for that.

But we really need to have the discussion on r-devel about exactly what C++
standard shall be supported.

| with some stub for throwing an error if a feature is used on a platform not
| supporting R_CPP. ?That should work for simple examples, but it may be hard to
| do the autoconf test. ?And of course, Rcpp is anything but "a simple example"
| so I don't even know if this is possible in theory.

We sort of do that, see the header Rcpp/inst/include/Rcpp/platform/compiler.h
(source path, installed drop the "inst/" part) which already checks for
supported compilers.
 
| Anyway, I know this is mostly noise, but wanted to remind you of the OS X
| issue.

Thanks.

Dirk