Experimental CXX_STD problem in R 3.4
C++ support across different platforms is now very heterogeneous. The standard is evolving rapidly but there are also platforms in current use that do not support the recent iterations of the standard. Our goal for R 3.4.0 is to give as much flexibility as possible. The default compiler is whatever you get "out of the box" without setting the "-std=" flag. This means different things on different platforms. If you need a specific standard there are various ways to request one, as described in the R-exts manual. On unix-alikes, the capabilities of the compiler are tested at configure time and appropriate flags chosen to support each standard. On Windows, the capabilities are hard-coded and correspond to the current version of Rtools, i.e. only C++98 and C++11 are currently supported. C++17 support is experimental and was added very recently. Clang 4.0.0, which was released last week, passes the configuration tests for C++17, and so does gcc 7.0.1, the pre-release version of gcc 7.1.0 which is due out later this year. The tests for C++17 features are, however, incomplete. I have just added some code to ensure that the compilation fails with an informative error message if a specific C++ standard is requested but the corresponding compiler has not been defined. Please test this. Martyn
From: R-devel <r-devel-bounces at r-project.org> on behalf of Dirk Eddelbuettel <edd at debian.org>
Sent: 18 March 2017 15:55
To: Jeroen Ooms
Cc: r-devel
Subject: Re: [Rd] Experimental CXX_STD problem in R 3.4
Sent: 18 March 2017 15:55
To: Jeroen Ooms
Cc: r-devel
Subject: Re: [Rd] Experimental CXX_STD problem in R 3.4
On 18 March 2017 at 14:21, Jeroen Ooms wrote:
| R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11
| / CXX14 / CXX17.
R 3.1.0 introduced CXX11 support. R 3.4.0 will have CXX14 support. So I
would only refer to the CXX17 part as experimental.
| However on most platforms, the R configuration seems to leave the
| CXX1Y and CXX1Z fields blank in "${R_HOME}/etc/Makeconf" (rather than
| falling back on default CXX). Therefore specifying e.g CXX_STD= CXX14
| will fail build with cryptic errors (due to compiling with CXX="")
That depends of course on the compiler found on the system. On my box (with
g++ being g++-6.2 which _defaults_ to C++14) all is well up to CXX1Y.
But I also have CXX1Z empty.
| I don't think this is intended? Some examples from r-devel on Windows:
|
| CXX11: https://win-builder.r-project.org/R8gg703OQSq5/
| CXX98: https://win-builder.r-project.org/mpVfXxk79FaN/
| CXX14: https://win-builder.r-project.org/L3BSMgAk4cQ7/
| CXX17: https://win-builder.r-project.org/3ETZXrgkg77I/
You can't expect CXX14 and CXX17 to work with the only available compiler
there, g++-4.9.3.
| Similar problems appear on Linux. I think the problem is that Makeconf
| contains e.g:
|
| CXX1Z =
| CXX1ZFLAGS =
| CXX1ZPICFLAGS =
| CXX1ZSTD =
|
| When CXX_STD contains any other unsupported value (e.g. CXX24) R
| simply falls back on the default CXX configuration. The same should
| probably happen for e.g. CXX17 when CXX1Z is unset in Makeconf?
Probably.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}