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 <e...@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-boun...@r-project.org [r-devel-boun...@r-project.org] on > behalf of Dirk Eddelbuettel [e...@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 | e...@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 | e...@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]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
