I would love to see optional c++0x support added for R.

If there is anything I can do to help, please let me know.

Sincerely,
Whit



On Mon, Oct 7, 2013 at 5:47 PM, Dirk Eddelbuettel <edd@debian.org> wrote:

>
> Hi Martyn,
>
> On 7 October 2013 at 21:18, Martyn Plummer wrote:
> | I don't see any harm in allowing optional C++11 support,
>
> That would be a nice step forward.
>
> | and it is no trouble to update the documentation to acknowledge the
> | existence of C++11 conforming compilers.
>
> Indeed.
>
> | However, the questions of what is possible, what is recommended, and what
> |  is required for CRAN submissions are distinct.
>
> You may be aware of the difficulties we as R package developers have with
> discussions involving CRAN maintainers.
>
> | 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.
>
> I used an existing macros from the GNU autoconf archive. It can certainly
> be
> tweaked. R's stack of configure logic is an impressive piece of work and I
> wasn't expecting this to flow through. It was meant to start a discussion.
>
> My principal points are that
>
>    i)  we do have compilers now that can support this, and
>
>    ii) we can test for their capabilities when R itself is compiled.
>
> | 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.
>
> Of course. All this can and should be discussed. I just wanted to get the
> ball rolling and had a choice between just emailing Kurt (as the configure
> and m4 point man) and emailing here.
>
> To the extent that c++0x support is also widely available, I do not see why
> one could not allow it either.  But that is a minor issue: I would really
> like us to (eventually) move beyond what is going to become a more and more
> constraining C++ standard.
>
> Optional support for deployments where C++11 is indeed available seems
> like a
> step in the right direction.
>
> Thanks for your feedback!
>
> Dirk
>
> | Martyn
> | ________________________________________
> | From: r-devel-bounces@r-project.org [r-devel-bounces@r-project.org] on
> behalf of Dirk Eddelbuettel [edd@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@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@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@debian.org | http://dirk.eddelbuettel.com
> |
> | ______________________________________________
> | R-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
> | -----------------------------------------------------------------------
> | This message and its attachments are strictly confidential. If you are
> | not the intended recipient of this message, please immediately notify
> | the sender and delete it. Since its integrity cannot be guaranteed,
> | its content cannot involve the sender's responsibility. Any misuse,
> | any disclosure or publication of its content, either whole or partial,
> | is prohibited, exception made of formally approved use
> | -----------------------------------------------------------------------
>
> --
> Dirk Eddelbuettel | edd@debian.org | http://dirk.eddelbuettel.com
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]

