llvm-svn: 139711

llvm-svn: 139032

llvm-svn: 138978

Reimplemented much of <istream> such that single character extractions do not check to see if this is the last character in the stream and thus never set eofbit.  This fixes http://llvm.org/bugs/show_bug.cgi?id=10817 .  This fix requires a recompiled libc++.dylib to be fully implemented.  The recompiled libc++.dylib is ABI compatible with that shipped on Lion.

llvm-svn: 138961

llvm-svn: 138726

llvm-svn: 137862

llvm-svn: 137617

llvm-svn: 137522

llvm-svn: 136596

llvm-svn: 136595

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.

llvm-svn: 136577

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.

llvm-svn: 136576

implementation of previous().

llvm-svn: 136547

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.

llvm-svn: 136546

more than just a bit broken. This one should compile and run without
infinite loops.

llvm-svn: 136545

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.

llvm-svn: 136542

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.

llvm-svn: 136540

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.

llvm-svn: 136539

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.

llvm-svn: 136538

llvm-svn: 136526

llvm-svn: 136291

llvm-svn: 136247

llvm-svn: 136232

llvm-svn: 135897

Optimization of string::operator< by M.E. O'Neill.  Discussion in http://llvm.org/bugs/show_bug.cgi?id=10461

llvm-svn: 135893

llvm-svn: 135873

llvm-svn: 135854

std::underlying_type.

llvm-svn: 135410

llvm-svn: 135393

llvm-svn: 135272

llvm-svn: 135271

issues with it.

llvm-svn: 135246

llvm-svn: 135045

Reverted to 134947.  Once I got into it, I discovered there were too many problems to fix in 135035.

llvm-svn: 135044

all platforms. Unfortunately a lot of this remains conditionally
compiled so as not to break Apple's ABI.

The new _LIBCPP_LOCALE__L_EXTENSIONS macro can be defined on other
platforms that support _l suffixes for all functions in order to use
them.

llvm-svn: 135035

llvm-svn: 134947

llvm-svn: 134815

glibc, for instance, it's a const char *.

llvm-svn: 134787

llvm-svn: 134783

traits.

To the best of my knowledge, this will not break the ABI for Apple.
However, it does introduce three publicly visible (although with
reserved name) functions that will fail to link against the just-shipped
Apple version of libc++. Since they are not used in any inline
functions, no actual breakage should occur.

If Howard doesn't want to put undefined functions (even internal ones)
into a header, they could be surrounded by additional conditional
compilation.

llvm-svn: 134781