libc++

问题 I just observed a strange issue with libc++ when using SFINAE to detect if a templated type is default constructible. The following is a minimal example I was able to come up with: #include <iostream> #include <type_traits> template <typename T> struct Dummy; template <> struct Dummy<int>{}; template <typename T, typename = void> struct has_dummy : std::false_type {}; template <typename T> struct has_dummy<C, std::enable_if_t<std::is_default_constructible<Dummy<T>>::value>> : std::true_type{}

问题 I'm using Xcode 4.3.1's C++11 language dialect along with libc++ as the standard library. The language support in this combination is amazing, but debugging is torture. Neither Xcode's "Summary Format" nor lldb's summary format features display any of the standard types (std::string, std::vector, etc.) with pretty printing. Writing a pretty printer for these types is highly non-trivial due to their complexity. (E.g., std::string is remarkably complex in libc++.) How in the world are other

问题 The std::sort of libcxx (llvm version of c++ standard library) calls the comparison predicate with the same element i.e., both the arguments of comparison functor refer to the same position in the sequence to be sorted. A reduced example to illustrate the point. $ cat a.cc #include <algorithm> #include <vector> #include <cassert> int main(int argc, char** argv) { int size = 100; std::vector<int> v(size); // Elements in v are unique. for (int i = 0; i < size; ++i) v[i] = i; std::sort(v.begin()

问题 After configuring a std::istringstream to throw exceptions when failbit is set I get no exceptions happening with libc++ (this is under linux with libc++ compiled with support from libcxxrt). I suppose this is a bug in libc++ or libcxxrt: #include <iostream> #include <sstream> template<typename T> std::istream &getvalue(std::istream &is, T &value, const T &default_value = T()) { std::stringstream ss; std::string s; std::getline(is, s, ','); ss << s; if((ss >> value).fail()) value = default

问题 Edit: this is not asking how to do std::make_heap the O(n) way, but rather whether this particular implementation is indeed O(n) The textbook way of building a heap in O(n) time is to successively build the heap from bottom up. But the implementation of std::make_heap on my Mac machine in libc++ is template <class _RandomAccessIterator, class _Compare> inline _LIBCPP_INLINE_VISIBILITY void make_heap(_RandomAccessIterator __first, _RandomAccessIterator __last, _Compare __comp) { #ifdef _LIBCPP

问题 When I try to include things like <unordered_map> it fails and says the file doesn't exist, while when I try to include <tr1/unordered_map> it works. however, the include files that are present also in c++03 are found, and are c++11 (like <vector> has move constructor). Also, headers that are only in c++11 and not in tr1 are found normally as well, like <thread> . Its like everything that was new in tr1 was just thrown into tr1 folder and everything else into normal include. Why is this

问题 The following (toy) program returns different things when linked against libstdc++ and libc++. Is this a bug in libc++ or do I not understand how istream eof() works? I have tried running it using g++ on linux and mac os x and clang on mac os x, with and without -std=c++0x. It was my impression that eof() does not return true until an attempt to read (by get() or something else) actually fails. This is how libstdc++ behaves, but not how libc++ behaves. #include <iostream> #include <sstream>

问题 It is used in libc++ on many template types such as tuple_element , tuple , etc. As far as I can tell there is no public documentation of what it does other than the commit message introducing it and this unit test in the clang project. 回答1: This attribute allows the ELF visibility of a type and (presumably) its vague linkage objects (vtable, typeinfos) to be controlled separately from the visibility of functions and data members of the type. This allows typeinfos and the vtable for, say,

问题 I'm trying to compile my projects on Arch Linux x64 using libc++ , libc++abi and clang++ 3.6.0 . The projects compile properly, but fail to link with the following error: error: CMakeFiles/main.cpp.o: undefined reference to symbol '__cxa_thread_atexit@@CXXABI_1.3.7' /usr/lib/libstdc++.so.6:-1: error: error adding symbols: DSO missing from command line I'm compiling and linking using the -stdlib=libc++ -lc++abi flags. Is there any additional library I should link? Am I missing a flag? 回答1:

问题 Edit/Update/Note: Just let clang use libstdc++. Has been working really well for me so far. =============================== In the past I have been able to succeed by doing something with cmake , but just now I discovered a buildit script inside the lib directory of the http://llvm.org/svn/llvm-project/libcxx/trunk project tree. This buildit script appears to not make use of libsupc++ which is what the cmake approach that I took earlier used. For instance, this guide shows one cmake