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 | [email protected] | http://dirk.eddelbuettel.com _______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
