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
between C++03 and C++0x and its effect on exceptions, and another two to
not test move construction when rvalue references are not available.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@135445 91177308-0d34-0410-b5e6-96231b3b80d8
itself non-throwing. Since nested_exception's destructor is
non-throwing, if B's destructor is not, this causes an error in C++03
mode due to the overriding function having a more lax specification.
This did not occur in C++0x mode as A's destructor was implicitly
non-throwing.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@135400 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@135035 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@134781 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C Automatic Reference Counting, where Objective-C object
pointers can have several different qualifiers (__strong, __weak,
__autoreleasing, __unsafe_unretained). These addressof() overloads are
only provided in ARC mode, and the __weak variant is conditionalized
on having weak-reference support in the ARC runtime.
For historical reasons, Clang provides these definitions itself, and
defines the macro _LIBCPP_PREDEFINED_OBJC_ARC_ADDRESSOF to note when
it as done so. The code belongs here, and this redundancy will be
eliminated in the future.
Addresses <rdar://problem/9658274>.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@133656 91177308-0d34-0410-b5e6-96231b3b80d8
