clang++

I have some strange troubles with Rcpp - it uses unpredictable C++ compiler. This question is somewhat similar to this question . I'm on OSX, I have 2 complilers - default clang and clang-omp with openmp support. Also I have following ~/.R/Makevars file (where I set up clang-omp as default compiler): CC=clang-omp CXX=clang-omp++ CFLAGS += -O3 -Wall -pipe -pedantic -std=gnu99 CXXFLAGS += -O3 -Wall -pipe -Wno-unused -pedantic -fopenmp The problem is that, the package I'm developing compiles with clang++ , not clang-omp++ . I also tried (as experiment to lacate issue) to change package src

Why am I getting the following linker error when using clang with libc++: $ clang++ -stdlib=libc++ po.cxx -lpoppler /tmp/po-QqlXGY.o: In function `main': po.cxx:(.text+0x33): undefined reference to `Dict::lookup(char*, Object*, std::__1::set<int, std::__1::less<int>, std::__1::allocator<int> >*)' clang: error: linker command failed with exit code 1 (use -v to see invocation) Where: $ nm -D /usr/lib/x86_64-linux-gnu/libpoppler.so | grep lookup | c++filt| grep \ Dict::lookup\( 00000000000c1870 T Dict::lookup(char*, Object*, std::set<int, std::less<int>, std::allocator<int> >*) Code is simply:

Up to Xcode 6 when typing clang --version we got the information on what LLVM version it was built: Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) But now with Xcode 7 we only get the following: Apple LLVM version 7.0.0 (clang-700.0.72) See https://gist.github.com/yamaya/2924292 in which an interesting comment says: Looking at the sources (src/CMakeLists.txt), it appears AppleClang is based on (approximately) the following LLVM branches: clang-700.0.72 => LLVM 3.7.0 clang-700.1.76 => LLVM 3.7.0 clang-700.1.81 => LLVM 3.7.0 clang-703.0.29 => LLVM 3.8.0 clang-703.0.31 => LLVM

Background Everybody agrees that using <typedef-name> = <type>; is equivalent to typedef <type> <typedef-name>; and that the former is to be preferred to the latter for various reasons (see Scott Meyers, Effective Modern C++ and various related questions on stackoverflow). This is backed by [dcl.typedef]: A typedef-name can also be introduced by an alias-declaration. The identifier following the using keyword becomes a typedef-name and the optional attribute-specifier-seq following the identifier appertains to that typedef-name. Such a typedef-name has the same semantics as if it were

I'm writing a C++ library and I would like to make my API throw exceptions for invalid parameters, but rely on asserts instead when the code is compiled with -fno-exceptions . Is there a way to detect at compile-time if I'm allowed to use exception handling? Note that I'm writing a header-only library, so I don't have a configure phase and I don't have access to the build system to simply define a macro on the command line (and I don't want to add burden to the user). Since the Standard doesn't have any concept of "-fno-exceptions", of course the solution could be compiler-dependent. In this

David Hollman recently tweeted the following example (which I've slightly reduced): struct FooBeforeBase { double d; bool b[4]; }; struct FooBefore : FooBeforeBase { float value; }; static_assert(sizeof(FooBefore) > 16); //---------------------------------------------------- struct FooAfterBase { protected: double d; public: bool b[4]; }; struct FooAfter : FooAfterBase { float value; }; static_assert(sizeof(FooAfter) == 16); You can examine the layout in clang on godbolt and see that the reason the size changed is that in FooBefore , the member value is placed at offset 16 (maintaining a full