[Rcpp-devel] long long

[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

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com