clang c++

[jwhite]

I've been fooling around with clang c++, and I've been having difficulty getting a simple c++ hello world to build.

My simple hello world program:

#include <iostream>

int main(int argc, char** argv) {
	std::cout << "Hello World!" << std::endl;
	return 0;
}

I can compile it with g++, but clang++ can't find the iostream header

$ clang++ helloworld.cpp 
helloworld.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^
1 error generated.

Has anyone had any luck with this? Am I missing something glaringly obvious?

[mmix]

http://llvm.org/docs/CodingStandards.html#ll_iostream

#include <iostream> is Forbidden

The use of #include <iostream> in library files is hereby forbidden. The primary reason for doing this is to support clients using LLVM libraries as part of larger systems. In particular, we statically link LLVM into some dynamic libraries. Even if LLVM isn't used, the static constructors are run whenever an application starts up that uses the dynamic library. There are two problems with this:

The time to run the static c'tors impacts startup time of applications — a critical time for GUI apps.
The static c'tors cause the app to pull many extra pages of memory off the disk: both the code for the static c'tors in each .o file and the small amount of data that gets touched. In addition, touched/dirty pages put more pressure on the VM system on low-memory machines.

Note that using the other stream headers (<sstream> for example) is not problematic in this regard — just <iostream>. However, raw_ostream provides various APIs that are better performing for almost every use than std::ostream style APIs. Therefore new code should always use raw_ostream for writing, or the llvm::MemoryBuffer API for reading files.
Use raw_ostream

LLVM includes a lightweight, simple, and efficient stream implementation in llvm/Support/raw_ostream.h, which provides all of the common features of std::ostream. All new code should use raw_ostream instead of ostream.

Unlike std::ostream, raw_ostream is not a template and can be forward declared as class raw_ostream. Public headers should generally not include the raw_ostream header, but use forward declarations and constant references to raw_ostream instances.

[jwhite]

You've just quoted the clang style guide, as in the style guide for the clang source. I'm not working on the clang source, but I'm just trying to build a simple clang program.

After digging around some more, I've found a few other things. I've tried compiling a new c++ hello world (one that doesn't use iostream).

#include <string>
#include <cstdio>

int main(int argc, char** argv) {
	std::string greeting = "Hello World!";
	printf("%s\n", greeting.c_str());
	return 0;
}

I can compile and run this fine with g++. With clang, I get the following output:

$ clang++ helloworld2.cpp 
helloworld2.cpp:1:10: fatal error: 'string' file not found
#include <string>
         ^
1 error generated.

I did learn, however, that you can pass the -v flag to clang, and it will display some information as to where the include directories are, etc.

$ clang++ helloworld2.cpp -v
clang version 2.8 (branches/release_28)
Target: x86_64-redhat-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-redhat-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name helloworld2.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.51.0.6 -v -resource-dir /usr/lib/clang/2.8 -ferror-limit 19 -fmessage-length 216 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-KHG1MA.s -x c++ helloworld2.cpp
clang -cc1 version 2.8 based upon llvm 2.8 hosted on x86_64-redhat-linux-gnu
ignoring nonexistent directory "/usr/include/c++/4.6.0"
ignoring nonexistent directory "/usr/include/c++/4.6.0/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.6.0/backward"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.6.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/clang/2.8/include
 /usr/include
End of search list.
helloworld2.cpp:1:10: fatal error: 'string' file not found
#include <string>
         ^
1 error generated.

As you can see above, it's looking for the includes in directories that don't exist. So, I went and added the correct /usr/include/c++/4.6.1/ directories, and still got an error:

$ clang++ helloworld2.cpp -v -I/usr/include/c++/4.6.1 -I/usr/include/c++/4.6.1/x86_64-redhat-linux/ -I/usr/include/c++/4.6.1/backward -I/usr/lib/gcc/x86_64-redhat-linux/4.6.1/
clang version 2.8 (branches/release_28)
Target: x86_64-redhat-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-redhat-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name helloworld2.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.51.0.6 -v -resource-dir /usr/lib/clang/2.8 -I /usr/include/c++/4.6.1 -I /usr/include/c++/4.6.1/x86_64-redhat-linux/ -I /usr/include/c++/4.6.1/backward -I /usr/lib/gcc/x86_64-redhat-linux/4.6.1/ -ferror-limit 19 -fmessage-length 216 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-GZPRH0.s -x c++ helloworld2.cpp
clang -cc1 version 2.8 based upon llvm 2.8 hosted on x86_64-redhat-linux-gnu
ignoring nonexistent directory "/usr/include/c++/4.6.0"
ignoring nonexistent directory "/usr/include/c++/4.6.0/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.6.0/backward"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.6.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.6.1
 /usr/include/c++/4.6.1/x86_64-redhat-linux
 /usr/include/c++/4.6.1/backward
 /usr/lib/gcc/x86_64-redhat-linux/4.6.1
 /usr/local/include
 /usr/lib/clang/2.8/include
 /usr/include
End of search list.
In file included from helloworld2.cpp:1:
In file included from /usr/include/c++/4.6.1/string:41:
In file included from /usr/include/c++/4.6.1/bits/char_traits.h:40:
/usr/include/c++/4.6.1/bits/stl_algobase.h:378:43: error: unexpected type name '_ValueTypeI': expected expression
      const bool __simple = (__is_trivial(_ValueTypeI)
                                          ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:383:40: error: non-type template argument of type 'bool const' is not an integral constant expression
      return std::__copy_move<_IsMove, __simple,
                                       ^~~~~~~~
/usr/include/c++/4.6.1/bits/stl_algobase.h:573:43: error: unexpected type name '_ValueType1': expected expression
      const bool __simple = (__is_trivial(_ValueType1)
                                          ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:578:49: error: non-type template argument of type 'bool const' is not an integral constant expression
      return std::__copy_move_backward<_IsMove, __simple,
                                                ^~~~~~~~
/usr/include/c++/4.6.1/bits/stl_algobase.h:731:32: error: expected ';' in 'for' statement specifier
      for (__decltype(__n + 0) __niter = __n;
                               ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:732:5: error: use of undeclared identifier '__niter'
           __niter > 0; --__niter, ++__first)
           ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:732:20: error: use of undeclared identifier '__niter'
           __niter > 0; --__niter, ++__first)
                          ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:732:27: error: expected ')'
           __niter > 0; --__niter, ++__first)
                                 ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:731:11: note: to match this '('
      for (__decltype(__n + 0) __niter = __n;
          ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:743:32: error: expected ';' in 'for' statement specifier
      for (__decltype(__n + 0) __niter = __n;
                               ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:744:5: error: use of undeclared identifier '__niter'
           __niter > 0; --__niter, ++__first)
           ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:744:20: error: use of undeclared identifier '__niter'
           __niter > 0; --__niter, ++__first)
                          ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:744:27: error: expected ')'
           __niter > 0; --__niter, ++__first)
                                 ^
/usr/include/c++/4.6.1/bits/stl_algobase.h:743:11: note: to match this '('
      for (__decltype(__n + 0) __niter = __n;
          ^
12 errors generated.

It appears to me now that there is just something broken about clang++ on Fedora 15.

---------- Post added at 02:00 PM ---------- Previous post was at 01:58 PM ----------

Well something is broken. Just found this: https://bugzilla.redhat.com/show_bug.cgi?id=729308

[stevea]

If you strace it's not finding the gcc iostreams (understandable). Withtout the include flle clang++ its pretty useless.

[fedvasu]

Originally Posted by mmix

http://llvm.org/docs/CodingStandards.html#ll_iostream

what if i had to compile it with clang++ in bsd and g++ in Linux , what then? is there no way to write c++ in a clean intersection of g++ and clang++.

LLVM guys what they are trying to accomplish push forward objective-C? i'm not gonna write code which g++ can't understand.