R 3.1.0 and C++11

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

R 3.1.0 and C++11

Dirk Eddelbuettel

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 | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Martyn Plummer-3
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: [hidden email] [[hidden email]] on behalf of Dirk Eddelbuettel [[hidden email]]
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 | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Dirk Eddelbuettel

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: [hidden email] [[hidden email]] on behalf of Dirk Eddelbuettel [[hidden email]]
| 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 | [hidden email] | http://dirk.eddelbuettel.com
|
| ______________________________________________
| [hidden email] 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 | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Whit Armstrong-3
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 <[hidden email]> 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: [hidden email] [[hidden email]] on
> behalf of Dirk Eddelbuettel [[hidden email]]
> | 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 | [hidden email] | http://dirk.eddelbuettel.com
> |
> | ______________________________________________
> | [hidden email] 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 | [hidden email] | http://dirk.eddelbuettel.com
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Romain François-2
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 <[hidden email]>
> 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: [hidden email]
>> [[hidden email]] on
>> behalf of Dirk Eddelbuettel [[hidden email]]
>> | 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 | [hidden email] | http://dirk.eddelbuettel.com
>> |
>> | ______________________________________________
>> | [hidden email] 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 | [hidden email] | http://dirk.eddelbuettel.com
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Michael Kane
I'd like to echo Whit's sentiment and hopefully warm up this thread.
C++11's new features and functionality give R users low-level tools (like
threads, mutexes, futures, date-time, and atomic types) that work across
platforms and wouldn't require other external libraries like boost.

Romain, will you be taking pull requests?

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Romain François-2
Le 03/11/2013 22:45, Michael Kane a écrit :
> I'd like to echo Whit's sentiment and hopefully warm up this thread.
> C++11's new features and functionality give R users low-level tools (like
> threads, mutexes, futures, date-time, and atomic types) that work across
> platforms and wouldn't require other external libraries like boost.

+1

portability is really important. One of the points is that by giving
means to assume a certain standard, we can write more portable code.

There has been lots of discussion about Boost.Thread, etc ... no need
for that if you have C++11.

> Romain, will you be taking pull requests?

Yes. Definitely. I will carefully review them.
Can give you write access too.

I'm getting a good feel of what C++11 brings while developping Rcpp11.
But I think it makes a lot of sense to write such an article with other
people as well.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Dirk Eddelbuettel
In reply to this post by Dirk Eddelbuettel

Following up on the thread spawned a while back, I just wanted to say that I
appreciate today's RSS serving of R-devel NEWS:

   CHANGES IN R-devel PACKAGE INSTALLATION

   There is _experimental_ support for compiling C++11 code in packages. The
   file ‘src/Makevars’ or ‘src/Makevars.win’ should define the macro
   ‘USE_CXX11 = true’. Where needed, an alternative C++11 compiler can be
   specified by setting macros ‘CXX11’, ‘CXX11FLAGS’ and so on, either when R
   is configured or in a personal ‘Makevars’ file. (The default is to use
   ‘$(CXX) -std=c++11’.)

Thanks for initial and incremental changes. They are appreciated.

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Dirk Eddelbuettel

On 2 December 2013 at 07:04, Dirk Eddelbuettel wrote:
|
| Following up on the thread spawned a while back, I just wanted to say that I
| appreciate today's RSS serving of R-devel NEWS:
|
|    CHANGES IN R-devel PACKAGE INSTALLATION
|
|    There is _experimental_ support for compiling C++11 code in packages. The
|    file ‘src/Makevars’ or ‘src/Makevars.win’ should define the macro
|    ‘USE_CXX11 = true’. Where needed, an alternative C++11 compiler can be
|    specified by setting macros ‘CXX11’, ‘CXX11FLAGS’ and so on, either when R
|    is configured or in a personal ‘Makevars’ file. (The default is to use
|    ‘$(CXX) -std=c++11’.)
|
| Thanks for initial and incremental changes. They are appreciated.

And now a big thanks to Martyn and anybody else in R Core who pushed this
through to the R 3.1.0 release this morning.

Having Makevars to let us say CXX_STD = CXX11 (plus the other variants) is a
real step forward, and relying on the information gleaned at configuration
time for R is sensible too.  

It's really good to have this, so thanks again.

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Martyn Plummer-3
On Thu, 2014-04-10 at 07:22 -0500, Dirk Eddelbuettel wrote:

> On 2 December 2013 at 07:04, Dirk Eddelbuettel wrote:
> |
> | Following up on the thread spawned a while back, I just wanted to say that I
> | appreciate today's RSS serving of R-devel NEWS:
> |
> |    CHANGES IN R-devel PACKAGE INSTALLATION
> |
> |    There is _experimental_ support for compiling C++11 code in packages. The
> |    file ‘src/Makevars’ or ‘src/Makevars.win’ should define the macro
> |    ‘USE_CXX11 = true’. Where needed, an alternative C++11 compiler can be
> |    specified by setting macros ‘CXX11’, ‘CXX11FLAGS’ and so on, either when R
> |    is configured or in a personal ‘Makevars’ file. (The default is to use
> |    ‘$(CXX) -std=c++11’.)
> |
> | Thanks for initial and incremental changes. They are appreciated.
>
> And now a big thanks to Martyn and anybody else in R Core who pushed this
> through to the R 3.1.0 release this morning.

Credit it due to Brian here.
Martyn

> Having Makevars to let us say CXX_STD = CXX11 (plus the other variants) is a
> real step forward, and relying on the information gleaned at configuration
> time for R is sensible too.  
>
> It's really good to have this, so thanks again.
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Gabor Grothendieck
In reply to this post by Romain François-2
On Tue, Oct 29, 2013 at 1:58 AM,  <[hidden email]> wrote:

> 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.
>

Unless you are willing to do it yourself currently Rtools on Windows uses
g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x .

Ubuntu 12.04 LTS also provides g++ 4.6.3.

g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11

More info at:
http://gcc.gnu.org/projects/cxx0x.html

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Martyn Plummer-3
On Thu, 2014-04-10 at 11:14 -0400, Gabor Grothendieck wrote:

> On Tue, Oct 29, 2013 at 1:58 AM,  <[hidden email]> wrote:
> > 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.
> >
>
> Unless you are willing to do it yourself currently Rtools on Windows uses
> g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x .
>
> Ubuntu 12.04 LTS also provides g++ 4.6.3.
>
> g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11
>
> More info at:
> http://gcc.gnu.org/projects/cxx0x.html

The R configure script is permissive and will enable "C++11" support if
your compiler accepts -std=c++0x. Obviously you will only get partial
support for the C++11 standard (But this is also true of some compilers
that accept -std=c++11). You may be OK if you just want C99 features,
which were missing from the C++98 standard, and features previously
introduced in the TR1 extension. But there are no guarantees.

Cross-platform support for C++11 is going to remain poor for some time
to come, I'm afraid.

Martyn
-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Romain François-2

Le 10 avr. 2014 à 17:58, Martyn Plummer <[hidden email]> a écrit :

> On Thu, 2014-04-10 at 11:14 -0400, Gabor Grothendieck wrote:
>> On Tue, Oct 29, 2013 at 1:58 AM,  <[hidden email]> wrote:
>>> 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.
>>>
>>
>> Unless you are willing to do it yourself currently Rtools on Windows uses
>> g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x .
>>
>> Ubuntu 12.04 LTS also provides g++ 4.6.3.
>>
>> g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11
>>
>> More info at:
>> http://gcc.gnu.org/projects/cxx0x.html
>
> The R configure script is permissive and will enable "C++11" support if
> your compiler accepts -std=c++0x. Obviously you will only get partial
> support for the C++11 standard (But this is also true of some compilers
> that accept -std=c++11). You may be OK if you just want C99 features,
> which were missing from the C++98 standard, and features previously
> introduced in the TR1 extension. But there are no guarantees.
>
> Cross-platform support for C++11 is going to remain poor for some time
> to come, I'm afraid.
>
> Martyn

What would be a good enough motivation for distributing a version of Rtools based on a more recent gcc, e.g. in the 4.8 series, which has much better coverage of the standard.

I don’t have the skills to build an Rtools distribution, but if I can help one way or another, please let me know. I could, perhaps with other interested parties sponsor someone’s time for example.

Romain
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 3.1.0 and C++11

Dirk Eddelbuettel
In reply to this post by Martyn Plummer-3

On 10 April 2014 at 15:58, Martyn Plummer wrote:
| The R configure script is permissive and will enable "C++11" support if
| your compiler accepts -std=c++0x. Obviously you will only get partial
| support for the C++11 standard (But this is also true of some compilers
| that accept -std=c++11). You may be OK if you just want C99 features,
| which were missing from the C++98 standard, and features previously
| introduced in the TR1 extension. But there are no guarantees.

Indeed. I am using that feature (of asking for C++11 and being guaranteed a
set of changes relative to C99) in the RcppCNPy upload that went onto CRAN
this morning --- as we now have consistent 'long long' support.  Which also
works with Rtools and g++ 4.6.*.

| Cross-platform support for C++11 is going to remain poor for some time
| to come, I'm afraid.

Precisely.  

One does have the option of using what R / CRAN now "C++11" incrementally by
taking what is provided where it is provided.

My simple example finally getting 'long long' via the cstdint header works
that way (on my machine, cstdint goes back to the oldest compiler I still
have, g++-4.4).  But it needs one of the extensions: -std=c++11 where
available, -std=c++0x on older systems.

And eg Martin Morgan's recent question of how to use 'unordered_map' should
work the same way: just turn on C++11 and depend on R 3.1.0. That header is
also provided at least as far back as 4.4.

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel