CXX_STD and configure.ac in packages

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

CXX_STD and configure.ac in packages

Martin Morgan
In C++ code for use in a R-3.1.0 package, my specific problem is that I would
like to use <unordered_map> if it is available, or <tr1/unordered_map> if not,
or <map> if all else fails.

I (think I) can accomplish this with configure.ac as

AC_INIT("DESCRIPTION")

CXX=`"${R_HOME}/bin/R" CMD config CXX`
CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`

AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT

Use of configure.ac does not seem to be entirely consistent with section 1.2.4
of Writing R Extensions, where one is advised that to use C++(11? see below)
code one should

     CXX_STD = CXX11

in Makevars(.win). My code does not require a compiler that supports the full
C++11 feature set. In addition, I do not understand the logic of setting a
variable that influences compiler flags in Makevars -- configure.ac will see a
compiler with inaccurate flags.

Is use of configure.ac orthogonal to setting CXX_STD=CXX11?

Some minor typos:

/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===================================================================
--- doc/manual/R-exts.texi (revision 65339)
+++ doc/manual/R-exts.texi (working copy)
@@ -2250,7 +2250,7 @@
  @subsection Using C++11 code

  @R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
  For full portability across platforms, all
  that can be assumed is approximate support for the C++98 standard (the
  widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
  support a flag @option{-std=c++0x}, but the latter only provides partial
  support for the C++11 standard.

-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
  file (or @file{Makevars.win} on Windows) should include the line

  @example
@@ -2329,7 +2329,7 @@
  anything other than the GNU version of C++98 and GNU extensions (which
  include TR1).  The default compiler on Windows is GCC 4.6.x and supports
  the @option{-std=c++0x} flag and some C++11 features (see
-@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
+@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
  platforms, it is necessary to select a different compiler for C++11, as
  described above, @emph{via} personal @file{Makevars} files.  For
  example, on OS X 10.7 or later one could select @command{clang++}.

--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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

Re: CXX_STD and configure.ac in packages

Dirk Eddelbuettel

Hi Martin,

On 30 March 2014 at 12:50, Martin Morgan wrote:
| In C++ code for use in a R-3.1.0 package, my specific problem is that I would
| like to use <unordered_map> if it is available, or <tr1/unordered_map> if not,
| or <map> if all else fails.

This non-standardization over the last decade caused a lot of headaches.  

We do have a set of tests in Rcpp (see includes/Rcpp/platform/compiler.h) to
find unordered maps and sets (based on the compiler version). Not too
elegant, but it works.

One possible alternative is to simply use Boost, which is now easy thanks to
the BH package.  Then Boost abstracts this for you and you use Boost for
unordered_map and/or unordered_set.
 
| I (think I) can accomplish this with configure.ac as
|
| AC_INIT("DESCRIPTION")
|
| CXX=`"${R_HOME}/bin/R" CMD config CXX`
| CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
|
| AC_CONFIG_HEADERS([src/config.h])
| AC_LANG(C++)
| AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
| AC_OUTPUT
|
| Use of configure.ac does not seem to be entirely consistent with section 1.2.4
| of Writing R Extensions, where one is advised that to use C++(11? see below)
| code one should
|
|      CXX_STD = CXX11
|
| in Makevars(.win). My code does not require a compiler that supports the full
| C++11 feature set. In addition, I do not understand the logic of setting a
| variable that influences compiler flags in Makevars -- configure.ac will see a
| compiler with inaccurate flags.

There were some earlier discussions. Basically, R 'learns' what it has
available when it is built, and the CXX_STD = CXX11 setting then selects
C++11 (or, on older compilers, C++0x) if available.

But you should be able to get with that. The tr1/ directory is by now pretty
old.  Looking at my current server, which has been around a few years and
upgraded, I see

edd@max:~$ ls -l /usr/include/c++/4.?/unordered_map
-rw-r--r-- 1 root root 2448 Jan 30  2013 /usr/include/c++/4.4/unordered_map
-rw-r--r-- 1 root root 1821 Jul  2  2012 /usr/include/c++/4.5/unordered_map
-rw-r--r-- 1 root root 1852 Jun 19  2013 /usr/include/c++/4.6/unordered_map
-rw-r--r-- 1 root root 1889 Sep 23  2013 /usr/include/c++/4.7/unordered_map
-rw-r--r-- 1 root root 1857 Nov 15 09:22 /usr/include/c++/4.8/unordered_map
edd@max:~$

Are you really going to get a compiler older than 4.4 (if in g++ world) ?

I'd try to avoid the configure dance unless you really feel you must have it.

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: CXX_STD and configure.ac in packages

Romain François-2
In reply to this post by Martin Morgan
Hi,

My advice would be to use SystemRequirements: C++11

As <unordered_map> is definitely a part of C++11, assuming this version of the standard gives it to you. Your package may not compile on platforms where a C++11 compiler is not available, but perhaps if this becomes a pattern, then such compilers will start to be available, as in the current version of OSX and recent enough versions of various linux distributions.

The subset of feature that the version of gcc gives you with Rtools might be enough.

Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which will expand to either unordered_map or tr1::unordered_map, all the condition compiling is done in Rcpp.

Romain

Le 30 mars 2014 à 21:50, Martin Morgan <[hidden email]> a écrit :

> In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use <unordered_map> if it is available, or <tr1/unordered_map> if not, or <map> if all else fails.
>
> I (think I) can accomplish this with configure.ac as
>
> AC_INIT("DESCRIPTION")
>
> CXX=`"${R_HOME}/bin/R" CMD config CXX`
> CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
>
> AC_CONFIG_HEADERS([src/config.h])
> AC_LANG(C++)
> AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
> AC_OUTPUT
>
> Use of configure.ac does not seem to be entirely consistent with section 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see below) code one should
>
>    CXX_STD = CXX11
>
> in Makevars(.win). My code does not require a compiler that supports the full C++11 feature set. In addition, I do not understand the logic of setting a variable that influences compiler flags in Makevars -- configure.ac will see a compiler with inaccurate flags.
>
> Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
>
> Some minor typos:
>
> /R-3-1-branch$ svn diff
> Index: doc/manual/R-exts.texi
> ===================================================================
> --- doc/manual/R-exts.texi (revision 65339)
> +++ doc/manual/R-exts.texi (working copy)
> @@ -2250,7 +2250,7 @@
> @subsection Using C++11 code
>
> @R{} can be built without a C++ compiler although one is available
> -(but not necessarily installed) or all known @R{} platforms.
> +(but not necessarily installed) on all known @R{} platforms.
> For full portability across platforms, all
> that can be assumed is approximate support for the C++98 standard (the
> widely used @command{g++} deviates considerably from the standard).
> @@ -2272,7 +2272,7 @@
> support a flag @option{-std=c++0x}, but the latter only provides partial
> support for the C++11 standard.
>
> -In order to use C++ code in a package, the package's @file{Makevars}
> +In order to use C++11 code in a package, the package's @file{Makevars}
> file (or @file{Makevars.win} on Windows) should include the line
>
> @example
> @@ -2329,7 +2329,7 @@
> anything other than the GNU version of C++98 and GNU extensions (which
> include TR1).  The default compiler on Windows is GCC 4.6.x and supports
> the @option{-std=c++0x} flag and some C++11 features (see
> -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
> +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
> platforms, it is necessary to select a different compiler for C++11, as
> described above, @emph{via} personal @file{Makevars} files.  For
> example, on OS X 10.7 or later one could select @command{clang++}.
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
> ______________________________________________
> [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: CXX_STD and configure.ac in packages

Martyn Plummer-3
Hi Martin,

Thanks for the patch. I have applied it. I also added CXX1X and friends to the list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config CXX1X` (It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's words, you want to do the configure dance.

The philosophy underlying C++ support in R is that there are only two standards - C++98 and C++11 - and that
you should write to one of those standards. Nobody should be writing new code that uses TR1 extensions now: they are
superseded by the new standard.

The map and unordered_map classes are a corner case, as they offer the same functionality but latter has much better
complexity guarantees, so it is tempting to use it when available.  But from a global perspective you should think of
C++98 and C++11 as two different languages.

Martyn


________________________________________
From: [hidden email] [[hidden email]] on behalf of Romain Francois [[hidden email]]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages

Hi,

My advice would be to use SystemRequirements: C++11

As <unordered_map> is definitely a part of C++11, assuming this version of the standard gives it to you. Your package may not compile on platforms where a C++11 compiler is not available, but perhaps if this becomes a pattern, then such compilers will start to be available, as in the current version of OSX and recent enough versions of various linux distributions.

The subset of feature that the version of gcc gives you with Rtools might be enough.

Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which will expand to either unordered_map or tr1::unordered_map, all the condition compiling is done in Rcpp.

Romain

Le 30 mars 2014 à 21:50, Martin Morgan <[hidden email]> a écrit :

> In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use <unordered_map> if it is available, or <tr1/unordered_map> if not, or <map> if all else fails.
>
> I (think I) can accomplish this with configure.ac as
>
> AC_INIT("DESCRIPTION")
>
> CXX=`"${R_HOME}/bin/R" CMD config CXX`
> CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
>
> AC_CONFIG_HEADERS([src/config.h])
> AC_LANG(C++)
> AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
> AC_OUTPUT
>
> Use of configure.ac does not seem to be entirely consistent with section 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see below) code one should
>
>    CXX_STD = CXX11
>
> in Makevars(.win). My code does not require a compiler that supports the full C++11 feature set. In addition, I do not understand the logic of setting a variable that influences compiler flags in Makevars -- configure.ac will see a compiler with inaccurate flags.
>
> Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
>
> Some minor typos:
>
> /R-3-1-branch$ svn diff
> Index: doc/manual/R-exts.texi
> ===================================================================
> --- doc/manual/R-exts.texi    (revision 65339)
> +++ doc/manual/R-exts.texi    (working copy)
> @@ -2250,7 +2250,7 @@
> @subsection Using C++11 code
>
> @R{} can be built without a C++ compiler although one is available
> -(but not necessarily installed) or all known @R{} platforms.
> +(but not necessarily installed) on all known @R{} platforms.
> For full portability across platforms, all
> that can be assumed is approximate support for the C++98 standard (the
> widely used @command{g++} deviates considerably from the standard).
> @@ -2272,7 +2272,7 @@
> support a flag @option{-std=c++0x}, but the latter only provides partial
> support for the C++11 standard.
>
> -In order to use C++ code in a package, the package's @file{Makevars}
> +In order to use C++11 code in a package, the package's @file{Makevars}
> file (or @file{Makevars.win} on Windows) should include the line
>
> @example
> @@ -2329,7 +2329,7 @@
> anything other than the GNU version of C++98 and GNU extensions (which
> include TR1).  The default compiler on Windows is GCC 4.6.x and supports
> the @option{-std=c++0x} flag and some C++11 features (see
> -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
> +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
> platforms, it is necessary to select a different compiler for C++11, as
> described above, @emph{via} personal @file{Makevars} files.  For
> example, on OS X 10.7 or later one could select @command{clang++}.
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[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: CXX_STD and configure.ac in packages

Martyn Plummer-3
On Mon, 2014-03-31 at 07:09 +0000, Martyn Plummer wrote:
> Hi Martin,
>
> Thanks for the patch. I have applied it. I also added CXX1X and friends to the list of approved variables for R CMD config.
> So you can now query the existence of C++11 support with `R CMD config CXX1X` (It is empty if C++11 support is not available)
> and then take appropriate action in your configure script if, in Dirk's words, you want to do the configure dance.
>
> The philosophy underlying C++ support in R is that there are only two standards - C++98 and C++11 - and that
> you should write to one of those standards.

A should add a clarification. The way I wrote this makes it sound like
an even-handed choice, but only C++98 has cross-platform support. If you
use C++11 then many users will not currently be able to use your code.

> Nobody should be writing new code that uses TR1 extensions now: they are
> superseded by the new standard.
>
> The map and unordered_map classes are a corner case, as they offer the same functionality but latter has much better
> complexity guarantees, so it is tempting to use it when available.  But from a global perspective you should think of
> C++98 and C++11 as two different languages.
>
> Martyn
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] on behalf of Romain Francois [[hidden email]]
> Sent: 31 March 2014 08:22
> To: Martin Morgan
> Cc: R-devel
> Subject: Re: [Rd] CXX_STD and configure.ac in packages
>
> Hi,
>
> My advice would be to use SystemRequirements: C++11
>
> As <unordered_map> is definitely a part of C++11, assuming this version of the standard gives it to you. Your package may not compile on platforms where a C++11 compiler is not available, but perhaps if this becomes a pattern, then such compilers will start to be available, as in the current version of OSX and recent enough versions of various linux distributions.
>
> The subset of feature that the version of gcc gives you with Rtools might be enough.
>
> Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which will expand to either unordered_map or tr1::unordered_map, all the condition compiling is done in Rcpp.
>
> Romain
>
> Le 30 mars 2014 à 21:50, Martin Morgan <[hidden email]> a écrit :
>
> > In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use <unordered_map> if it is available, or <tr1/unordered_map> if not, or <map> if all else fails.
> >
> > I (think I) can accomplish this with configure.ac as
> >
> > AC_INIT("DESCRIPTION")
> >
> > CXX=`"${R_HOME}/bin/R" CMD config CXX`
> > CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
> >
> > AC_CONFIG_HEADERS([src/config.h])
> > AC_LANG(C++)
> > AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
> > AC_OUTPUT
> >
> > Use of configure.ac does not seem to be entirely consistent with section 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see below) code one should
> >
> >    CXX_STD = CXX11
> >
> > in Makevars(.win). My code does not require a compiler that supports the full C++11 feature set. In addition, I do not understand the logic of setting a variable that influences compiler flags in Makevars -- configure.ac will see a compiler with inaccurate flags.
> >
> > Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
> >
> > Some minor typos:
> >
> > /R-3-1-branch$ svn diff
> > Index: doc/manual/R-exts.texi
> > ===================================================================
> > --- doc/manual/R-exts.texi    (revision 65339)
> > +++ doc/manual/R-exts.texi    (working copy)
> > @@ -2250,7 +2250,7 @@
> > @subsection Using C++11 code
> >
> > @R{} can be built without a C++ compiler although one is available
> > -(but not necessarily installed) or all known @R{} platforms.
> > +(but not necessarily installed) on all known @R{} platforms.
> > For full portability across platforms, all
> > that can be assumed is approximate support for the C++98 standard (the
> > widely used @command{g++} deviates considerably from the standard).
> > @@ -2272,7 +2272,7 @@
> > support a flag @option{-std=c++0x}, but the latter only provides partial
> > support for the C++11 standard.
> >
> > -In order to use C++ code in a package, the package's @file{Makevars}
> > +In order to use C++11 code in a package, the package's @file{Makevars}
> > file (or @file{Makevars.win} on Windows) should include the line
> >
> > @example
> > @@ -2329,7 +2329,7 @@
> > anything other than the GNU version of C++98 and GNU extensions (which
> > include TR1).  The default compiler on Windows is GCC 4.6.x and supports
> > the @option{-std=c++0x} flag and some C++11 features (see
> > -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
> > +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
> > platforms, it is necessary to select a different compiler for C++11, as
> > described above, @emph{via} personal @file{Makevars} files.  For
> > example, on OS X 10.7 or later one could select @command{clang++}.
> >
> > --
> > Computational Biology / Fred Hutchinson Cancer Research Center
> > 1100 Fairview Ave. N.
> > PO Box 19024 Seattle, WA 98109
> >
> > Location: Arnold Building M1 B861
> > Phone: (206) 667-2793
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [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

-----------------------------------------------------------------------
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: CXX_STD and configure.ac in packages

Romain François-2
Le 31 mars 2014 à 12:20, Martyn Plummer <[hidden email]> a écrit :

> On Mon, 2014-03-31 at 07:09 +0000, Martyn Plummer wrote:
>> Hi Martin,
>>
>> Thanks for the patch. I have applied it. I also added CXX1X and friends to the list of approved variables for R CMD config.
>> So you can now query the existence of C++11 support with `R CMD config CXX1X` (It is empty if C++11 support is not available)
>> and then take appropriate action in your configure script if, in Dirk's words, you want to do the configure dance.
>>
>> The philosophy underlying C++ support in R is that there are only two standards - C++98 and C++11 - and that
>> you should write to one of those standards.
>
> A should add a clarification. The way I wrote this makes it sound like
> an even-handed choice, but only C++98 has cross-platform support. If you
> use C++11 then many users will not currently be able to use your code.

OTOH, if nobody goes there, the need for C++11 might not be perceived as important by people who take care of cross platform support.

Probably not Martin’s fight. One can do the gymnastics to get an unordered_map with C++98 (through boost, tr1, etc ...), but C++11 brings a great combination of new features that make it a better language, and I agree that it is almost a new language. And once you start using it, it is hard to look back.

>> Nobody should be writing new code that uses TR1 extensions now: they are
>> superseded by the new standard.
>>
>> The map and unordered_map classes are a corner case, as they offer the same functionality but latter has much better
>> complexity guarantees, so it is tempting to use it when available.  But from a global perspective you should think of
>> C++98 and C++11 as two different languages.
>>
>> Martyn
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] on behalf of Romain Francois [[hidden email]]
>> Sent: 31 March 2014 08:22
>> To: Martin Morgan
>> Cc: R-devel
>> Subject: Re: [Rd] CXX_STD and configure.ac in packages
>>
>> Hi,
>>
>> My advice would be to use SystemRequirements: C++11
>>
>> As <unordered_map> is definitely a part of C++11, assuming this version of the standard gives it to you. Your package may not compile on platforms where a C++11 compiler is not available, but perhaps if this becomes a pattern, then such compilers will start to be available, as in the current version of OSX and recent enough versions of various linux distributions.
>>
>> The subset of feature that the version of gcc gives you with Rtools might be enough.
>>
>> Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which will expand to either unordered_map or tr1::unordered_map, all the condition compiling is done in Rcpp.
>>
>> Romain
>>
>> Le 30 mars 2014 à 21:50, Martin Morgan <[hidden email]> a écrit :
>>
>>> In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use <unordered_map> if it is available, or <tr1/unordered_map> if not, or <map> if all else fails.
>>>
>>> I (think I) can accomplish this with configure.ac as
>>>
>>> AC_INIT("DESCRIPTION")
>>>
>>> CXX=`"${R_HOME}/bin/R" CMD config CXX`
>>> CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
>>>
>>> AC_CONFIG_HEADERS([src/config.h])
>>> AC_LANG(C++)
>>> AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
>>> AC_OUTPUT
>>>
>>> Use of configure.ac does not seem to be entirely consistent with section 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see below) code one should
>>>
>>>   CXX_STD = CXX11
>>>
>>> in Makevars(.win). My code does not require a compiler that supports the full C++11 feature set. In addition, I do not understand the logic of setting a variable that influences compiler flags in Makevars -- configure.ac will see a compiler with inaccurate flags.
>>>
>>> Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
>>>
>>> Some minor typos:
>>>
>>> /R-3-1-branch$ svn diff
>>> Index: doc/manual/R-exts.texi
>>> ===================================================================
>>> --- doc/manual/R-exts.texi    (revision 65339)
>>> +++ doc/manual/R-exts.texi    (working copy)
>>> @@ -2250,7 +2250,7 @@
>>> @subsection Using C++11 code
>>>
>>> @R{} can be built without a C++ compiler although one is available
>>> -(but not necessarily installed) or all known @R{} platforms.
>>> +(but not necessarily installed) on all known @R{} platforms.
>>> For full portability across platforms, all
>>> that can be assumed is approximate support for the C++98 standard (the
>>> widely used @command{g++} deviates considerably from the standard).
>>> @@ -2272,7 +2272,7 @@
>>> support a flag @option{-std=c++0x}, but the latter only provides partial
>>> support for the C++11 standard.
>>>
>>> -In order to use C++ code in a package, the package's @file{Makevars}
>>> +In order to use C++11 code in a package, the package's @file{Makevars}
>>> file (or @file{Makevars.win} on Windows) should include the line
>>>
>>> @example
>>> @@ -2329,7 +2329,7 @@
>>> anything other than the GNU version of C++98 and GNU extensions (which
>>> include TR1).  The default compiler on Windows is GCC 4.6.x and supports
>>> the @option{-std=c++0x} flag and some C++11 features (see
>>> -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
>>> +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
>>> platforms, it is necessary to select a different compiler for C++11, as
>>> described above, @emph{via} personal @file{Makevars} files.  For
>>> example, on OS X 10.7 or later one could select @command{clang++}.
>>>
>>> --
>>> Computational Biology / Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N.
>>> PO Box 19024 Seattle, WA 98109
>>>
>>> Location: Arnold Building M1 B861
>>> Phone: (206) 667-2793
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [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
>
> -----------------------------------------------------------------------
> This message and its attachments are strictly confiden...{{dropped:9}}

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

Re: CXX_STD and configure.ac in packages

Martin Morgan
On 03/31/2014 04:30 AM, Romain François wrote:
> Le 31 mars 2014 à 12:20, Martyn Plummer <[hidden email]> a écrit :
>
>> On Mon, 2014-03-31 at 07:09 +0000, Martyn Plummer wrote:
>>> Hi Martin,
>>>
>>> Thanks for the patch. I have applied it. I also added CXX1X and friends to the list of approved variables for R CMD config.
>>> So you can now query the existence of C++11 support with `R CMD config CXX1X` (It is empty if C++11 support is not available)
>>> and then take appropriate action in your configure script if, in Dirk's words, you want to do the configure dance.

Thanks, this is what I was looking for.

>>>
>>> The philosophy underlying C++ support in R is that there are only two standards - C++98 and C++11 - and that
>>> you should write to one of those standards.
>>
>> A should add a clarification. The way I wrote this makes it sound like
>> an even-handed choice, but only C++98 has cross-platform support. If you
>> use C++11 then many users will not currently be able to use your code.

Yes, the Writing R Extensions section at first seduced me into thinking that I
could get broad support for C++11 with a simple macro, but obviously that can
only come from the underlying compilers and R is making no guarantees about these.

> OTOH, if nobody goes there, the need for C++11 might not be perceived as important by people who take care of cross platform support.
>
> Probably not Martin’s fight. One can do the gymnastics to get an unordered_map with C++98 (through boost, tr1, etc ...), but C++11 brings a great combination of new features that make it a better language, and I agree that it is almost a new language. And once you start using it, it is hard to look back.
>
>>> Nobody should be writing new code that uses TR1 extensions now: they are
>>> superseded by the new standard.

For me unordered_map is a small part of a large mostly C code base; using it
instead of map has substantial benefits, but restricting package use to C++11
isn't really on the table in this particular case.

I'll take Martyn's philosophical statement that for R there are only two
standards -- C++98 and C++11, with attendant trade-offs -- as a guiding
principle and as a pragmatic solution avoid my complicated unordered_map
configure dance for now.

Thanks all for the various inputs.

Martin Morgan

>>>
>>> The map and unordered_map classes are a corner case, as they offer the same functionality but latter has much better
>>> complexity guarantees, so it is tempting to use it when available.  But from a global perspective you should think of
>>> C++98 and C++11 as two different languages.
>>>
>>> Martyn
>>>
>>> ________________________________________
>>> From: [hidden email] [[hidden email]] on behalf of Romain Francois [[hidden email]]
>>> Sent: 31 March 2014 08:22
>>> To: Martin Morgan
>>> Cc: R-devel
>>> Subject: Re: [Rd] CXX_STD and configure.ac in packages
>>>
>>> Hi,
>>>
>>> My advice would be to use SystemRequirements: C++11
>>>
>>> As <unordered_map> is definitely a part of C++11, assuming this version of the standard gives it to you. Your package may not compile on platforms where a C++11 compiler is not available, but perhaps if this becomes a pattern, then such compilers will start to be available, as in the current version of OSX and recent enough versions of various linux distributions.
>>>
>>> The subset of feature that the version of gcc gives you with Rtools might be enough.
>>>
>>> Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which will expand to either unordered_map or tr1::unordered_map, all the condition compiling is done in Rcpp.
>>>
>>> Romain
>>>
>>> Le 30 mars 2014 à 21:50, Martin Morgan <[hidden email]> a écrit :
>>>
>>>> In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use <unordered_map> if it is available, or <tr1/unordered_map> if not, or <map> if all else fails.
>>>>
>>>> I (think I) can accomplish this with configure.ac as
>>>>
>>>> AC_INIT("DESCRIPTION")
>>>>
>>>> CXX=`"${R_HOME}/bin/R" CMD config CXX`
>>>> CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
>>>>
>>>> AC_CONFIG_HEADERS([src/config.h])
>>>> AC_LANG(C++)
>>>> AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
>>>> AC_OUTPUT
>>>>
>>>> Use of configure.ac does not seem to be entirely consistent with section 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see below) code one should
>>>>
>>>>    CXX_STD = CXX11
>>>>
>>>> in Makevars(.win). My code does not require a compiler that supports the full C++11 feature set. In addition, I do not understand the logic of setting a variable that influences compiler flags in Makevars -- configure.ac will see a compiler with inaccurate flags.
>>>>
>>>> Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
>>>>
>>>> Some minor typos:
>>>>
>>>> /R-3-1-branch$ svn diff
>>>> Index: doc/manual/R-exts.texi
>>>> ===================================================================
>>>> --- doc/manual/R-exts.texi    (revision 65339)
>>>> +++ doc/manual/R-exts.texi    (working copy)
>>>> @@ -2250,7 +2250,7 @@
>>>> @subsection Using C++11 code
>>>>
>>>> @R{} can be built without a C++ compiler although one is available
>>>> -(but not necessarily installed) or all known @R{} platforms.
>>>> +(but not necessarily installed) on all known @R{} platforms.
>>>> For full portability across platforms, all
>>>> that can be assumed is approximate support for the C++98 standard (the
>>>> widely used @command{g++} deviates considerably from the standard).
>>>> @@ -2272,7 +2272,7 @@
>>>> support a flag @option{-std=c++0x}, but the latter only provides partial
>>>> support for the C++11 standard.
>>>>
>>>> -In order to use C++ code in a package, the package's @file{Makevars}
>>>> +In order to use C++11 code in a package, the package's @file{Makevars}
>>>> file (or @file{Makevars.win} on Windows) should include the line
>>>>
>>>> @example
>>>> @@ -2329,7 +2329,7 @@
>>>> anything other than the GNU version of C++98 and GNU extensions (which
>>>> include TR1).  The default compiler on Windows is GCC 4.6.x and supports
>>>> the @option{-std=c++0x} flag and some C++11 features (see
>>>> -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
>>>> +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
>>>> platforms, it is necessary to select a different compiler for C++11, as
>>>> described above, @emph{via} personal @file{Makevars} files.  For
>>>> example, on OS X 10.7 or later one could select @command{clang++}.
>>>>
>>>> --
>>>> Computational Biology / Fred Hutchinson Cancer Research Center
>>>> 1100 Fairview Ave. N.
>>>> PO Box 19024 Seattle, WA 98109
>>>>
>>>> Location: Arnold Building M1 B861
>>>> Phone: (206) 667-2793
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> ______________________________________________
>>> [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
>>
>> -----------------------------------------------------------------------
>> 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
>> -----------------------------------------------------------------------
>


--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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