[prev in list] [next in list] [prev in thread] [next in thread]
List: r-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
From: Martin Morgan <mtmorgan () fhcrc ! org>
Date: 2014-03-31 14:09:09
Message-ID: 53397705.9050608 () fhcrc ! org
[Download RAW message or body]
On 03/31/2014 04:30 AM, Romain François wrote:
> Le 31 mars 2014 à 12:20, Martyn Plummer <plummerm@iarc.fr> 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: r-devel-bounces@r-project.org [r-devel-bounces@r-project.org] on behalf \
> > > of Romain Francois [romain@r-enthusiasts.com]
> > > 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 <mtmorgan@fhcrc.org> 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
> > > >
> > > > ______________________________________________
> > > > R-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> > > ______________________________________________
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > > -----------------------------------------------------------------------
> > > This message and its attachments are strictly confidenti...{{dropped:8}}
> > >
> > > ______________________________________________
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > -----------------------------------------------------------------------
> > This message and its attachments are strictly confidential. If you are
> > not the intended recipient of this message, please immediately notify
> > the sender and delete it. Since its integrity cannot be guaranteed,
> > its content cannot involve the sender's responsibility. Any misuse,
> > any disclosure or publication of its content, either whole or partial,
> > is prohibited, exception made of formally approved use
> > -----------------------------------------------------------------------
>
--
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic