[Rcpp-devel] Using Rcpp with C++11 and clang

[Dirk Eddelbuettel]

Michael,

On 28 August 2012 at 20:54, Michael Braun wrote:
| Dirk:
| 
| Thanks for the kind words, although I'm not sure that 2 packages constitutes a flood.
| 
| The only reason I was using c++11 was to access some mathematical functions in TR1.  I can work around that, so I do not have to send any C++11 code to CRAN.

Can you more specific?  I did some related tests a while back comparing RNGs
from Boost, C++ TR1 and C++-11 (as I recall) [and in short, C++-11 and Boost
were not faster, to my dismay].  One issue is that these headers keep moving
(every so slowly...)
 
| But still, playing around with some more, the issue appears to be with libc++.  When -std=c++11, clang links to libc++ by default, while gcc and intel both link to libstdc++.  If I set -stdlib=libstdc++ in clang, it all works. For some reason, it appears that libstdc++ has tr1/unordered_map, but libc++ does not.  

Well tr1/ already existed four or five years ago with g++ 4.2.*. 

I expect it to disappear eventually as the standard rolls out. Similarly with
tr1/unordered_map which we often used for hash map. On my system, this now
actually sits in the top-level of g++ 4.6, so no more tr1/unordered_map but
just unordered_map.

So You may actually need to either use configure magic here, or specify a
minimum compiler version, or punt and use Boost's.
 
| The problem is that combining C++11 and libstdc++ is giving me some problems with other libraries, and not all of my code goes into a CRAN package.  So it would be great if Rcpp were libc++ - compatible, even if CRAN is not.  For example, would it be possible to undefine the HAS_TR1_UNORDERED_MAP macro for a Mac + clang + libc++ combination?

Sure -- If you propose a patch (preferably including some regression tests
for it) and also demonstrate that it breaks no other system, particularly
Linux as used by the CRAN gatekeeper (eg Debian testing) as well as Windows
(eg using win-builder), I will consider it.  Having 80+ CRAN packages depend
on Rcpp limits my willingness to do 'wild changes' in the configuration.  And
the last time I made such changes, it cost me two follow-up releases (as
essentially Rcpp 0.9.12 and 0.9.13 were cleanups for what got into 0.9.11).

Finally, not owning a Mac limits by motivation for writing such patches
myself as well as my ability to test them, as you can probably understand.

Cheers, Dirk

| 
| Michael
| 
| 
| On Aug 28, 2012, at 3:09 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
| 
| > 
| > Hi Michael,
| > 
| > Congrats on your recent flooding of CRAN with packages :)
| > 
| > On 28 August 2012 at 18:46, Michael Braun wrote:
| > | Is it possible that there is some kind of incompatibility among clang, libc++ and Rcpp? Consider this super-simple example (filename is  tr1.cpp):
| > | 
| > | #include <Rcpp.h>
| > | RcppExport SEXP testtr1() {
| > |   return(Rcpp::wrap(0));
| > | }
| > | 
| > | If I compile it as a dynamic library with clang, I get:
| > | 
| > | clang -O3  -m64 -msse4.2 -std=c++11 -stdlib=libc++ -I/Library/Frameworks/R.framework/Headers -I/Library/Frameworks/R.framework/Resources/library/Rcpp/include   -c tr1.cpp -o tr1.o 
| > | 
| > | In file included from tr1.cpp:1:
| > | In file included from /Library/Frameworks/R.framework/Resources/library/Rcpp/include/Rcpp.h:27:
| > | /Library/Frameworks/R.framework/Resources/library/Rcpp/include/RcppCommon.h:143:10: fatal error: 'tr1/unordered_map' file not found
| > | #include <tr1/unordered_map>
| > |          ^
| > | 1 error generated.
| > | 
| > | This works fine with the Intel compiler, as well as with gcc version 4.6.1.
| > | 
| > | Looking at RcppCommon.h, I see that there are a number of checks, including the definition of HAS_TR!_UNORDERED_MAP.   Is it possible that this code defines this macro for clang, when it shouldn't?
| > | 
| > | The version of clang I am using is:
| > | 
| > | Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)
| > | Target: x86_64-apple-darwin12.1.0
| > | Thread model: posix
| > | 
| > | Rcpp is version 0.9.13.  My OS is Mac OSX 10.8.1, and I have installed XCode 4.4.1, with the latest command line tools.
| > | 
| > | I see that this issue has been brought up in the past, but I have not been able to find a resolution.  Since clang appears to be Apple's preferred compiler in XCode, I thought you might like to know about this, and perhaps let me know if I have made some kind of mistake.
| > 
| > There are two (to three) distinct issues here:
| > 
| > i)  clang -- and I do from time to time test with clang which works just fine
| >    "as is", ie on my Linux box I simply say this in ~/.R/Makevars
| > 
| >    CXX=clang++
| >    CC=clang
| > 
| >    and R builds just fine, as does Rcpp.  As I follow whatever Ubuntu gives
| >    me, I am still at clang 3.0, but I expect no changes from clang 3.1
| > 
| > ii) c++11 -- and Romain and I were enthusiastic about it early as brings so
| >    many new features.  Only to be told by CRAN (and one vocal person in
| >    particular) that this is non-standard, non-portable, non-kosher, ...
| >    so we relented.  I still have this in ~/.R/Makevars
| > 
| >    #CXXFLAGS=            -g  -O3 -Wall -pipe -pedantic -Wno-variadic-macros 
| >    #CXXFLAGS=            -g0 -O3 -Wall -pipe -pedantic -Wno-variadic-macros 
| >    #CXXFLAGS= -std=c++0x -g  -O3 -Wall -pipe -pedantic -Wno-variadic-macros 
| > 
| >    so all it takes is to enable -std=c++0x.  AFAIK clang++ uses that switch too.
| > 
| >    But do understand that such code cannot go to CRAN until the
| >    powers-that-be decide otherwise.
| > 
| > Now, there could possibly be an intersection of issues with i) AND ii) but I
| > don't think so. Similarly, there could as always be something special going
| > on with OS X, in which case someone else will need to help you with the finer
| > aspects of that environment.
| > 
| > Hth,  Dirk
| > 
| > 
| > -- 
| > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com  
| 
| -----------------------------------------------
| Michael Braun 
| Associate Professor of Marketing
| MIT Sloan School of Management
| 617-253-3436
| braunm at mit.edu
| http://braunm.scripts.mit.edu/
| 
| application/pkcs7-signatu [Press RETURN to save to a file]

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com