clang++

问题 It seems that clang++ (I tried clang 3.2) treats the name of a template class as a instantiated class, not a template for any occurence within the class scope. For example, the following codes template <template <class> class T> class A {}; template <typename T> class B { A<B> member; // ^---- clang++ treats B as an instantiated class // but I want it to be a template here // this code could compile in g++ }; int main() { B<int> b; return 0; } What should I do to compile that? 回答1: C++03

问题 I'm trying to compile a program I found on the web using Clang++. The Makefile generates this command: clang++ -c -arch x86_64 -msse3 -std=c++11 -stdlib=libstdc++ -Wno-missing-field-initializers -Wno-missing-prototypes -Wreturn-type -Wno-non-virtual-dtor -Wno-exit-time-destructors -Wformat -Wmissing-braces -Wparentheses -Wno-switch -Wunused-function -Wunused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas -Wno-shadow -Wno-four

问题 I'm trying the fold expression with clang 3.6 '--std=c++1z', but something I don't quite get. The function that I'm testing is: auto minus = [](auto... args) { return (args - ...); }; ... std::cout << minus(10, 3, 2) << std::endl; according to n4191, I'm expecting it expands as a left fold to (10 - 3) - 2 which gives result 5, however, the result is 9, which seems to be a right fold expansion, i.e. 10 - (3 - 2) Am I missing anything or mis-understand n4191? Thanks 回答1: n4191 was revised by

问题 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) 回答1: 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

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

问题 This is a scaled down version of a problem I am facing with clang++ on Mac OS X. This was seriously edited to better reflect the genuine problem (the first attempt to describe the issue was not exhibiting the problem). The failure I have this big piece of software in C++ with a large set of symbols in the object files, so I'm using -fvisibility=hidden to keep my symbol tables small. It is well known that in such a case one must pay extra attention to the vtables, and I suppose I face this

问题 The following code contains a fold expression, which afaiu is a c++17 feature: template <typename... T> static bool variable_length_or(const T ... v) { return (v || ...); } bool foo () { return variable_length_or(true, false, true, false); } what I find odd is that both g++ and clang++ seem to be fine with it when building with -std=c++14 (compiler-explorer). They do create a warning: <source>:2:16: warning: pack fold expression is a C++17 extension [-Wc++17-extensions] return (v || ...);

问题 I am uncertain if it is a bug in Clang 3.2 or a violation of C++03, but it appears that explicit instantiation of templated constructors for template classes fails, but explicit instantiation of templated member functions of template classes succeeds. For instance, the following compiles without a problem with both clang++ and g++: template<typename T> class Foo { public: template<typename S> void Bar( const Foo<S>& foo ) { } }; template class Foo<int>; template class Foo<float>; template

问题 I've tried to compile simple hello world on Fedora 20 with Clang, and I get the following output: d.cpp:1:10: fatal error: 'iostream' file not found #include <iostream> I don't have any idea how to resolve it. 回答1: Point 3 solved the problem for me. 1. Had the same issue, fedora 21::clang 3.5.0: clang++ -std=c++14 -pedantic -Wall test_01.cpp -o test_01 -v 2. ignoring nonexistent directory "/usr/lib/gcc/i686-redhat-linux/4.9.2/include" #include "..." search starts here: #include <...> search

问题 I'm trying to compile some C++ code (including C++11 features) on OS X 10.8 using the clang++ compiler. I have a makefile that generates the object files OK, then on the command: clang++ -o Analysis.so -shared DataFile.o CR39DataFile.o I get tons of errors about symbol(s) not found for architecture x86_64. The code works fine on a *nix system using g++ and changing the compiler flags appropriately for C++11 support. To compile the *.o I am doing it like: clang++ -c -Wall -std=c++11 -stdlib