From romain at r-enthusiasts.com  Tue Oct 29 06:58:33 2013
From: romain at r-enthusiasts.com (romain at r-enthusiasts.com)
Date: Tue, 29 Oct 2013 06:58:33 +0100
Subject: [Rd] R 3.1.0 and C++11
In-Reply-To: <CAMi=pg5aRiFG7s+f4bERE6QQe+D7dH1Y_b9Q6AsH3A7Gz0M-qw@mail.gmail.com>
References: <21073.63553.888272.510490@max.nulle.part>
	<31E214B6DF75104E942856C2F74953CB0505C0F9@exchange>
	<21075.11278.577153.103691@max.nulle.part>
	<CAMi=pg5aRiFG7s+f4bERE6QQe+D7dH1Y_b9Q6AsH3A7Gz0M-qw@mail.gmail.com>
Message-ID: <478ce69b232b57db8fa74fa93e5a646a@r-enthusiasts.com>

Le 2013-10-29 03:01, Whit Armstrong a ?crit?:
> I would love to see optional c++0x support added for R.

c++0x was the name given for when this was in development. Now c++11 is 
a published standard backed by implementations by major compilers.
people need to stop calling it c++0x

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

Come here https://github.com/romainfrancois/cpp11_article where I'm 
writing an article on C++11 and what would be the benefits.

Romain

> Sincerely,
> Whit
>
> On Mon, Oct 7, 2013 at 5:47 PM, Dirk Eddelbuettel <edd at 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 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 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 at debian.org | http://dirk.eddelbuettel.com
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] R 3.1.0 and C++11
romain at r-enthusiasts.com