libc++ now mostly works on FreeBSD with libcxxrt and this patch applied to the base system:
http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110920/e666632c/xlocale-0001.obj
Summary of tests on FreeBSD:
****************************************************
Results for /root/libcxx/test:
using FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix
with -std=c++0x -stdlib=libc++ -I/root/libcxx/include -L/root/libcxx/build/lib
----------------------------------------------------
sections without tests : 1
sections with failures : 48
sections without failures: 1015
+ ----
total number of sections : 1064
----------------------------------------------------
number of tests failed : 145
number of tests passed : 4179
+ ----
total number of tests : 4324
****************************************************
(Many due to this clang version not supporting C++ atomics)
More fixes to follow...
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@140245 91177308-0d34-0410-b5e6-96231b3b80d8
This was checked in without review. It is not clear its reasonable to
include with libc++ at all, and needs discussion at a highlevel before
moving forward.
It's also completely lacking tests, and included several bugs in the
implementation.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@136577 91177308-0d34-0410-b5e6-96231b3b80d8
Original change:
Destruct elements of hash tables when removing individual entries from
the hash_table. I think this is the correct solution to PR10507, but I'm
not sure since this is a little bit cargo-culted. Howard, please review.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@136576 91177308-0d34-0410-b5e6-96231b3b80d8
the hash_table. I think this is the correct solution to PR10507, but I'm
not sure since this is a little bit cargo-culted. Howard, please review.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@136546 91177308-0d34-0410-b5e6-96231b3b80d8
together to get it working with code, and is neither optimal
(erase(Iterator, Iterator) calculates the previous iterator twice,
rather than calculating the previous iterator of the first one, then
advancing it until the second is found) nor complete (splice() was not
implemented). Most of the implementation is borrowed from forward_list
via using-declarations.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@136542 91177308-0d34-0410-b5e6-96231b3b80d8
avoids bugs where, when the allocator's size_type was smaller than int,
the multiplication or division would cause integral promotions and, with
two different integer types as arguments, deduction of the template
arguments would fail.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@136540 91177308-0d34-0410-b5e6-96231b3b80d8
are two motivations for this.
First, this allows users who are specializing __gnu_ext::hash to
continue doing so without changing their code.
Second, SGI specifies hash overloads for char* and const char* that
perform a hash of the string, not of the pointer.
In order to support this, the hashing code for string is factored out.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@136539 91177308-0d34-0410-b5e6-96231b3b80d8
the type name 'data_type', which is specified by the SGI spec as being
the correct type name for the mapped type. The second is an overload of
insert found in standard containers, taking an iterator as a 'hint'
(which we ignore in the standard containers as well). libstdc++'s
implementation includes these overloads, and they are needed to make
insert_iterator work (which I suspect is the real motivation for
including them in the standard containers).
The motivation for including these overloads of insert and leaving the
mapped_type typedef is to make it easier for clients to migrate to the
standard containers.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@136538 91177308-0d34-0410-b5e6-96231b3b80d8
