[Rd] CXX_STD and configure.ac in packages

Mon Mar 31 16:09:09 CEST 2014

On 03/31/2014 04:30 AM, Romain François wrote:
> Le 31 mars 2014 à 12:20, Martyn Plummer <plummerm at 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 at r-project.org [r-devel-bounces at r-project.org] on behalf of Romain Francois [romain at 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 at 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
>>>> - at uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
>>>> + at 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 at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> ______________________________________________
>>> R-devel at 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 at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> -----------------------------------------------------------------------
>> This message and its attachments are strictly confidential. If you are
>> not the intended recipient of this message, please immediately notify
>> the sender and delete it. Since its integrity cannot be guaranteed,
>> its content cannot involve the sender's responsibility. Any misuse,
>> any disclosure or publication of its content, either whole or partial,
>> is prohibited, exception made of formally approved use
>> -----------------------------------------------------------------------
>

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