[Rd] R 3.1.0 and C++11

[Martyn Plummer]

I don't see any harm in allowing optional C++11 support, and it is no trouble to update the documentation to acknowledge the existence of C++11 conforming compilers. However, the questions of what is possible, what is recommended, and what is required for CRAN submissions are distinct.

I have a couple of comments on the macro:
a) Your version implies mandatory C++11 support. One needs AX_CXX_COMPILE_STDCXX_11(noext,optional) for optional support.
b) I find it unhelpful that the macro picks up the partial C++11 support in gcc 4.7 via the -std=c++0x flag, so I would edit (and rename) the macro to remove this.

Martyn
________________________________________
From: r-devel-bounces at r-project.org [r-devel-bounces at r-project.org] on behalf of Dirk Eddelbuettel [edd at debian.org]
Sent: 07 October 2013 01:54
To: R-devel org
Subject: [Rd] R 3.1.0 and C++11

I would like to bring up two issues concerning C++11.


First, the R-devel manuals contain incorrect statements regarding C++11:

  i)   R-exts.texi:

       Although there is a 2011 version of the C++ standard, it is not yet
       fully implemented (nor is it likely to be widely available for some
       years) and portable C++ code needs to follow the 1998 standard
       (and not use features from C99).

  ii)  R-ints.texi:

       The type `R_xlen_t' is made available to packages in C header
       `Rinternals.h': this should be fine in C code since C99 is
       required.  People do try to use R internals in C++, but C++98
       compilers are not required to support these types (and there are
       currently no C++11 compilers).

But since the summer we have g++ and clang with working C++11 implementations:

  iii) g++ implements C++11:
       http://isocpp.org/blog/2013/05/gcc-4.8.1-released-c11-feature-complete

  iv)  llvm/clang++ implements C++11:
       http://isocpp.org/blog/2013/06/llvm-3.3-is-released

I would suggest to change the wording prior to the release of R 3.1.0 next
year as it is likely that even Microsoft will by then have a fully-conformant
compiler (per Herb Sutter at a recent talk in Chicago). If it helped, I would
be glad to provide minimal patches to the two .texi files.

Moreover, the C++ Standards Group is working towards closing the delta
between standards being adopted, and compilers being released. They expect
corresponding compilers for C++14 (a "patch" release for C++11 expected to be
ready next spring) to be available within a year---possibly during 2014.


Second, the current R Policy regarding C++11 is unnecessarily strict. I would
propose to treat the availability of C++11 extensions more like the
availability of OpenMP: something which configure can probe at build time,
and which can be deployed later via suitable #ifdef tests.

As a proof of concept, I added this macro from the autoconf archive to the
m4/ directory of R-devel:

  http://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html

and made a one-line change to configure.ac (indented two spaces just for email)

  edd at max:~/svn/r-devel$ svn di configure.ac
  Index: configure.ac
  ===================================================================
  --- configure.ac      (revision 64031)
  +++ configure.ac      (working copy)
  @@ -906,6 +906,7 @@

   AC_LANG_PUSH(C++)
   AC_OPENMP
  +AX_CXX_COMPILE_STDCXX_11(noext)
   AC_LANG_POP(C++)

   ### *** ObjC compiler
  edd at max:~/svn/r-devel$

After running 'aclocal -Im4; autoheader; autoconf', the configure test then
properly detected C++11 (or, in one case, C++0x) on four different compilers:

  [ g++-4.7 case, Ubuntu 13.04 ]
  checking whether g++ supports C++11 features by default... no
  checking whether g++ supports C++11 features with -std=c++11... no
  checking whether g++ supports C++11 features with -std=c++0x... yes

  [ CC=clang CXX=clang++ (3.1), Ubuntu 13.04 ]
  checking whether clang++ accepts -M for generating dependencies... yes
  checking for clang++ option to support OpenMP... unsupported
  checking whether clang++ supports C++11 features by default... no
  checking whether clang++ supports C++11 features with -std=c++11... yes

  [ g++-4.8 case, Debian testing ]
  checking whether g++ supports C++11 features by default... no
  checking whether g++ supports C++11 features with -std=c++11... yes

  [ CC=clang CXX=clang++ (3.2), Debian testing ]
  checking whether clang++ supports C++11 features by default... no
  checking whether clang++ supports C++11 features with -std=c++11... yes

It would be easy to another #define to config.h.in.


And of course, I understand that R Core is comprised primarily of C
programmers.  But to those of us who lean more towards C++ than C, the step
towards C++11 is a big one, and a very exciting one.  More and more upstream
authors are considering right now whether to switch to C++11-only.  I expect
such switches to become more common as time pass. C++11 provides a lot -- and
preventing programmers from using these tools cannot be in our interest.

I think that the timing of the next R release will be a good opportunity to
permit use of C++11 where compilers support it -- as a wide range of sites
will already be capable of deploying it.

Thanks, Dirk

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

______________________________________________
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}}